InnoDBテーブルとMyISAMテーブルの結合
組織、組織ユーザー、組織部門などのメタレベルデータを含むテーブルのセットがあります。これらのテーブルはすべて、書き込み操作がほとんどなく、大量に読み取られます。また、テーブルのサイズは非常に小さくなります（レコードの最大数は約30K〜40Kになります）
別のテーブルストアのセットOLTP請求トランザクション、ユーザーアクションなど、読み取りと書き込みの両方が重いデータ。これらのテーブルは非常に巨大になります（テーブルあたり約3,000万レコード）
最初のテーブルセットではMyISAMを使用し、2番目のテーブルセットではInnoDbエンジンを使用する予定です。私たちの機能の多くは、これら2つのセットのテーブルでの結合も必要とします。
MyISAMテーブルをInnoDBテーブルと結合する際にパフォーマンスの問題はありますか？また、この種の設計で発生する可能性のある他の問題（dbバックアップ、チューニングなど）はありますか？
フィードバックをいただければ幸いです。
私にすぐに飛び出すのはMyISAM。
アスペクト＃1：JOIN自体
MyISAMとInnoDBが関係する結合がある場合は常に、MyISAMがクエリと [〜＃〜] mvcc [〜＃に関与しているため、InnoDBテーブルは行レベルのロックではなくテーブルレベルのロック動作になります。 〜] はMyISAMデータには適用できません。 [〜＃〜] mvcc [〜＃〜] 場合によっては、InnoDBに適用することさえできません。
アスペクト＃2：MyISAMの関与
別の見方をすれば、MyISAMテーブルがINSERT、UPDATE、またはDELETEを介して更新されている場合、JOINクエリに含まれるMyISAMテーブルは他のDB接続からロックされ、JOINクエリはMyISAMテーブルが読み取れるまで待機する必要があります。残念ながら、JOINクエリにInnoDBとMyISAMが混在している場合、InnoDBテーブルは、書き込みが保留されるため、JOINクエリのMyISAMパートナーのように断続的にロックされる必要があります。
MVCCは、READ-UNCOMMITTEDおよびREPEATABLE-READトランザクションが正常に機能し、データの特定のビューを他のトランザクションで使用できるようにすることを引き続き許可することに注意してください。 READ-COMMITTEDとSERIALIZABLE について同じことを言うことはできません。
アスペクト＃3：クエリオプティマイザ
MySQLは、インデックスカーディナリティに依存して、最適化されたEXPLAINプランを決定します。 MyISAMテーブルでは、多くのINSERT、UPDATE、およびDELETEが発生するまで、インデックスのカーディナリティは安定しています。これにより、MyISAMテーブルに対して定期的にOPTIMIZE TABLEを実行できます。 InnoDBインデックスのカーディナリティは決して安定していません!!! SHOW INDEXES FROM *innodbtable*;を実行すると、そのコマンドを実行するたびにインデックスのカーディナリティが変化するのがわかります。これは、InnoDBがカーディナリティを推定するためにインデックスに飛び込むためです。 InnoDBテーブルに対してOPTIMIZE TABLEを実行しても、テーブルを最適化するだけです。 OPTIMIZE TABLEは内部でANALYZE TABLEを実行して、テーブルに対するインデックス統計を生成します。これはMyISAMで機能します。 InnoDBはそれを無視します。
私からのアドバイスは、すべてを行ってすべてをInnoDBに変換し、それに応じて設定を最適化することです。
更新2012-12-1815：56 EDT
信じられないかもしれませんが、 SELECT FORUPDATE 中に参加しているInnoDB/MyISAMにはまだオープンチケットがあります。あなたがそれを読むならば、それは次のように解像度を要約します： それをしないでください!!! 。
MyISAMテーブルではトランザクション管理が処理されないため、トランザクション管理が適切に機能するか、まったく機能しないと思います。