インデックスは必ずしもパフォーマンスを向上させるわけではありません。何が起こっているのかをよりよく理解するには、explainを含めると役に立ちます。 さまざまなクエリに対して。
私の推測では、id_stateにインデックスがあります。 またはid_state, id_mp whereを満たすために使用できます 句。その場合、order byのない最初のクエリ このインデックスを使用します。かなり速いはずです。インデックスがない場合でも、これにはordersのページを順番にスキャンする必要があります テーブル、それでもかなり高速になる可能性があります。
次に、creation_dateにインデックスを追加すると 、MySQLは、order byの代わりにそのインデックスを使用することを決定します 。これには、インデックスの各行を読み取り、対応するデータページをフェッチして、whereを確認する必要があります。 条件を設定し、列を返します（一致する場合）。この読み取りは、「ページ」の順序ではなく、インデックスで指定されているため、非常に非効率的です。ランダム読み取りは非常に非効率的です。
さらに悪いことに、limitがある場合でも 、まだ全体を読む必要があります 結果セット全体が必要なため、テーブル。 38レコードのソートを保存しましたが、非常に非効率的なクエリを作成しました。
ちなみに、ordersの場合、この状況は大幅に悪化します テーブルが使用可能なメモリに収まりません。次に、「スラッシング」と呼ばれる状態が発生します。この状態では、新しいレコードごとに新しいI/O読み取りが生成される傾向があります。したがって、ページに100個のレコードがある場合、そのページを100回読み取る必要がある場合があります。
orders(id_state, id_mp, creation_date)にインデックスを付けることで、これらすべてのクエリをより高速に実行できます。 。 where 句は最初の2列とorder byを使用します 最後を使用します。