Co na mě okamžitě vyskočí, je MyISAM .
ASPECT #1:Samotný JOIN
Kdykoli dojde ke spojení zahrnujícím MyISAM a InnoDB, tabulky InnoDB skončí se zámkem na úrovni tabulky namísto zamykání na úrovni řádků kvůli zapojení MyISAM do dotazu a MVCC nelze použít na data MyISAM. MVCC v některých případech nelze dokonce použít na InnoDB.
ASPECT #2:Zapojení MyISAM
Z jiného pohledu, pokud jsou nějaké tabulky MyISAM aktualizovány pomocí INSERT, UPDATE nebo DELETE, tabulky MyISAM zahrnuté v dotazu JOIN budou uzamčeny z jiných připojení DB a dotaz JOIN musí počkat, dokud nebude možné číst tabulky MyISAM. Bohužel, pokud je v dotazu JOIN směs InnoDB a MyISAM, tabulky InnoDB by musely zaznamenat přerušovaný zámek jako jejich partneři MyISAM v dotazu JOIN, protože by jim bylo zdržováno psaní.
ASPECT #3:Optimalizátor dotazů
MySQL se při určování optimalizovaného plánu EXPLAIN spoléhá na kardinalitu indexu. Kardinalita indexu je v tabulkách MyISAM stabilní, dokud v tabulce neproběhne mnoho INSERT, UPDATE a DELETE, pomocí kterých můžete pravidelně spouštět OPTIMIZE TABLE proti tabulkám MyISAM. Kardinalita indexu InnoDB NENÍ NIKDY STABILNÍ!!! Pokud spustíte SHOW INDEXES FROM *innodbtable*; , uvidíte, že se mohutnost indexu změní při každém spuštění tohoto příkazu. To proto, že InnoDB provede ponory do indexu, aby odhadl mohutnost. I když spustíte OPTIMIZE TABLE proti tabulce InnoDB, která pouze defragmentuje tabulku. OPTIMIZE TABLE spustí ANALYZE TABLE interně pro generování statistik indexu podle tabulky. To funguje pro MyISAM. InnoDB to ignoruje.
Moje rada pro vás je jít do toho a vše převést na InnoDB a podle toho optimalizovat svá nastavení.
AKTUALIZACE 2012-12-18 15:56 EDT
Věřte tomu nebo ne, stále existuje otevřený lístek pro připojení k InnoDB/MyISAM během VÝBĚRU AKTUALIZACE . Pokud si to přečtete, shrnuje to rozlišení takto:NEDĚLEJTE TO !!! .