回答:
ここにいくつかの落とし穴があります
MyISAMキーキャッシュとInnoDBバッファープールの適切なサイズを選択する方法について、以前に作成して投稿したクエリをいくつか示します。
FULLTEXTインデックスを持つMyISAMテーブルを見つけるには、次のクエリを実行します。
select tbl.table_schema,tbl.table_name from
(
select table_schema,table_name
from information_schema.tables
where engine='MyISAM'
and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
select table_schema,table_name
from information_schema.statistics
where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);MySQL 5.6にアップグレードするまで、このクエリから得られるものはすべてInnoDBに変換できません。
最大の問題は、innodbがトランザクションであることだと思います。MySQLライブラリがアプリケーションでデフォルトでauto_commitによって使用されているかどうかを知りたいでしょう。
たとえば、Pythonは自動コミットしません。つまり、アプリケーションが接続を閉じる直前に行を挿入していた場合、その挿入はinnodbに変更した後にロールバックされるようになります。たとえば、Pythonスクリプトは、必ずconnection.commit（）を呼び出す必要があります。
もう1つの違いは、複数行の挿入または更新の前後にあります。単一の複数行挿入を検討してください
insert into tbl values (...row1...), (...row2...), (...rowN....);行3での一意のキーの衝突など、なんらかのエラーが発生した場合にどうなるかを検討します。MyISAMを使用すると、最初の2行が書き込まれます。innodbの下では、書き込まれるすべての行がロールバックされ、そのようなエラーが発生しても何も書き込まれません。
innodbを使用すると、デッドロックの世界に入ります。これらは、作業が行われないようにするような頻度で発生しない限り、本質的に悪くはありません。ただし、アプリケーションは、デッドロックを予測して適切に処理するようにコーディングする必要があります（ほとんどの場合、再試行を意味します）。
メモリ/ストレージの制限を考慮してください。InnodbはMyISAMよりも多くのリソースを必要とします。すべてのテーブルに対応するのに十分な大きさのバッファープールを維持するのに十分なRAMがある場合は、最適です。
大きな主キーを持つテーブルを探します。Innodbのクラスター化インデックス付けは、各セカンダリインデックスが対応する行のPKの別のコピーを保持することを意味します。2つのセカンダリインデックスがある場合、各行のPKは3回格納されます（PK +各インデックス）。pkが複数の列と大きなデータ型（たとえば、char（N））にまたがっている場合、インデックス要件がinnodbでどのように急速に爆発するかを確認できます。