Това, което веднага ми изскача, е MyISAM .
АСПЕКТ №1:Самото JOIN
Всеки път, когато има обединения, включващи MyISAM и InnoDB, таблиците InnoDB ще имат поведение на заключване на ниво таблица вместо заключване на ниво ред поради участието на MyISAM в заявката и MVCC не може да се приложи към данните на MyISAM. MVCC в някои случаи дори не може да се приложи към InnoDB.
АСПЕКТ №2:Участието на MyISAM
От друга гледна точка, ако някакви MyISAM таблици се актуализират чрез INSERT, UPDATE или DELETE, MyISAM таблиците, включени в заявка JOIN, ще бъдат заключени от други DB връзки и JOIN заявката трябва да изчака, докато MyISAM таблиците могат да бъдат прочетени. За съжаление, ако има смесица от InnoDB и MyISAM в заявката JOIN, таблиците InnoDB ще трябва да изпитат периодично заключване като партньорите на MyISAM в заявката JOIN, поради спиране на писането.
АССПЕКТ №3:Оптимизатор на заявки
MySQL разчита на мощността на индекса, за да определи оптимизиран план EXPLAIN. Кардиналността на индекса е стабилна в таблиците MyISAM, докато не се случат много INSERT, UPDATE и DELETE, чрез които периодично можете да изпълнявате OPTIMIZE TABLE срещу таблиците MyISAM. Кардиналността на индекса на InnoDB НИКОГА не е СТАБИЛНА !!! Ако стартирате SHOW INDEXES FROM *innodbtable*; , ще виждате промяна в кардиналността на индекса всеки път, когато изпълнявате тази команда. Това е така, защото InnoDB ще направи потапяне в индекса, за да оцени мощността. Дори ако стартирате OPTIMIZE TABLE срещу таблица на InnoDB, това само ще дефрагментира таблицата. OPTIMIZE TABLE ще стартира ANALYZE TABLE вътрешно за генериране на индексна статистика спрямо таблицата. Това работи за MyISAM. InnoDB го игнорира.
Моят съвет към вас е да положите всички усилия и да конвертирате всичко в InnoDB и съответно да оптимизирате настройките си.
АКТУАЛИЗИРАНЕ 2012-12-18 15:56 EDT
Вярвате или не, все още има отворен билет за присъединяване към InnoDB/MyISAM по време на SELECT FOR UPDATE . Ако го прочетете, той обобщава резолюцията по следния начин:НЕ ГО ПРАВЕТЕ !!! .
