私にすぐに飛び出すのはMyISAM 。
アスペクト＃1：参加自体
MyISAMとInnoDBが関係する結合がある場合は常に、クエリと MVCC MyISAMデータには適用できません。 MVCC 場合によっては、InnoDBに適用することさえできません。
アスペクト＃2：MyISAMの関与
別の見方をすれば、MyISAMテーブルがINSERT、UPDATE、またはDELETEを介して更新されている場合、JOINクエリに含まれるMyISAMテーブルは他のDB接続からロックされ、JOINクエリはMyISAMテーブルが読み取れるまで待機する必要があります。残念ながら、JOINクエリにInnoDBとMyISAMが混在している場合、書き込みが保留されるため、InnoDBテーブルはJOINクエリのMyISAMパートナーのように断続的にロックされる必要があります。
ASPECT＃3：クエリオプティマイザー
MySQLは、インデックスカーディナリティに依存して、最適化されたEXPLAINプランを決定します。インデックスのカーディナリティは、多くのINSERT、UPDATE、およびDELETEがテーブルで発生するまで、MyISAMテーブルで安定しています。これにより、定期的にOPTIMIZE TABLEを実行できます。 MyISAMテーブルに対して。 InnoDBインデックスのカーディナリティは決して安定していません!!! SHOW INDEXES FROM *innodbtable*;を実行した場合 、そのコマンドを実行するたびに、インデックスのカーディナリティが変化するのがわかります。これは、InnoDBがカーディナリティを推定するためにインデックスに飛び込むためです。 OPTIMIZE TABLEを実行しても InnoDBテーブルに対しては、テーブルを最適化するだけです。 OPTIMIZE TABLE ANALYZE TABLEを実行します テーブルに対してインデックス統計を生成するために内部的に。これはMyISAMで機能します。 InnoDBはそれを無視します。
私からのアドバイスは、すべてを調べてすべてをInnoDBに変換し、それに応じて設定を最適化することです。
UPDATE 2012-12-18 15:56 EDT
信じられないかもしれませんが、まだInnoDB/MyISAMのオープンチケットが参加していますSELECT FOR UPDATE 。読んだ場合、解像度は次のように要約されます。実行しないでください!!! 。