Det, der springer ud med det samme, er MyISAM .
ASPECT #1 :JOIN selve
Når der er joinforbindelser, der involverer MyISAM og InnoDB, vil InnoDB-tabeller ende med at have låseadfærd på tabelniveau i stedet for rækkeniveaulåsning på grund af MyISAM's involvering i forespørgslen og MVCC kan ikke anvendes på MyISAM-dataene. MVCC kan ikke engang anvendes på InnoDB i nogle tilfælde.
ASPECT #2 :MyISAM's involvering
Fra et andet perspektiv, hvis nogen MyISAM-tabeller bliver opdateret via INSERTs, UPDATEs eller DELETEs, vil MyISAM-tabellerne involveret i en JOIN-forespørgsel blive låst fra andre DB-forbindelser, og JOIN-forespørgslen skal vente, indtil MyISAM-tabellerne kan læses. Desværre, hvis der er en blanding af InnoDB og MyISAM i JOIN-forespørgslen, vil InnoDB-tabellerne skulle opleve en intermitterende lås ligesom deres MyISAM-partnere i JOIN-forespørgslen på grund af at blive holdt op med at skrive.
ASPECT #3:Query Optimizer
MySQL er afhængig af indekskardinalitet for at bestemme en optimeret EXPLAIN-plan. Indekskardinalitet er stabil i MyISAM-tabeller, indtil der sker en masse INSERTs, UPDATEs og DELETEs med tabellen, hvorved du med jævne mellemrum kan køre OPTIMIZE TABLE mod MyISAM-tabellerne. InnoDB indekskardinalitet er ALDRIG STABIL!!! Hvis du kører SHOW INDEXES FROM *innodbtable*; , vil du se indekskardinaliteten ændre sig, hver gang du kører den kommando. Det er fordi InnoDB vil dykke ned i indekset for at estimere kardinaliteten. Også selvom du kører OPTIMIZE TABLE mod en InnoDB-tabel, vil det kun defragmentere tabellen. OPTIMIZE TABLE vil køre ANALYZE TABLE internt for at generere indeksstatistik mod tabellen. Det virker for MyISAM. InnoDB ignorerer det.
Mit råd til dig er at gå helt ud og konvertere alt til InnoDB og optimere dine indstillinger i overensstemmelse hermed.
OPDATERING 2012-12-18 15:56 EDT
Tro det eller ej, der er stadig en åben billet på InnoDB/MyISAM, der deltager under en VÆLG TIL OPDATERING . Hvis du læser den, opsummerer den opløsningen som følger:GØR DET IKKE !!! .