これは驚くほど大きなパフォーマンスの違いですが、私は貢献しているかもしれないいくつかのことを考えることができます。
MyISAMは、歴史的にInnoDBよりも速いと見なされていましたが、最近のバージョンのInnoDBでは、はるかに小さいユースケースの場合に当てはまります。 MyISAMは通常、読み取り専用テーブルのテーブルスキャンの方が高速です。他のほとんどのユースケースでは、InnoDBの高速化が一般的です。頻繁に何倍も速くなります。テーブルロックは、MyISAMのほとんどの私のMySQLの使用の中で死にかけています。
MyISAMはキーバッファにインデックスをキャッシュします。おそらく、キーバッファーを小さすぎると設定して、いくらか大きなテーブルのインデックスを効果的にキャッシュすることはできません。
MyISAMは、OSディスクキャッシュ内の.MYDファイルからテーブルデータをキャッシュするOSに依存します。 OSのメモリが不足している場合、ディスクキャッシュのダンプが開始されます。それはディスクからの読み取りを強制する可能性があります。
InnoDBはインデックスとデータを両方とも独自のメモリバッファにキャッシュします。 OS Xではサポートされていませんが、innodb_flush_methodをO_DIRECTに設定すると、ディスクキャッシュも使用しないようにOSに指示できます。
通常、InnoDBはデータとインデックスを16kbページでバッファします。クエリ間で@eidの値をどのように変更するかに応じて、以前のクエリのディスク読み込みのために、1つのクエリのデータを既にキャッシュしている可能性があります。
インデックスが同じであることを確認してください。 MySQLがインデックスを使用しているかどうかを確認するには、説明を使用します。 show create tableやshow indexes fromの代わりにdescribeの出力を含めたので、entity_idが複合インデックスの一部であるかどうかはわかりません。コンポジットインデックスの最初の部分でない場合は、使用されません。あなたは、MySQLの比較的最近のバージョンを使用している場合は
、クエリを実行する前に、次のコマンドを実行します。
セットプロファイリング= 1;
これによりセッションのクエリプロファイリングが有効になります。クエリを実行した後、
プロファイルを実行します。
これは、利用可能なプロファイルのクエリ一覧を表示します。私はそれがデフォルトで最後の20を保持すると思います。クエリが最初のものだったとします。
クエリ1のプロファイルを表示します。
次に、クエリを実行する各段階の期間が表示されます。これは、クエリを遅くする原因(たとえば、テーブルのロック、ソート、一時テーブルの作成など)を判断する場合に非常に役立ちます。
新しいMyISAMテーブルを作成し、そのテーブルに対してクエリを計るという、かなり簡単なテストで、この推測を確認できました。 –