パフォーマンスの違いはおそらく e.id_dernier_fichierによる JOINに使用されるインデックスに含まれていますが、e.codega そのに参加していない インデックス。
両方のテーブルとそれらのすべてのインデックスの完全な定義がなければ、確実に判断することはできません。また、2つのクエリに2つのEXPLAINPLANを含めると役立ちます。
ただし、今のところ、いくつか詳しく説明することができます...
INDEXがクラスター化されている場合（これは主キーにも適用されます）、データは実際にはINDEXの順序で物理的に格納されます。これは、位置xが必要であることを知っていることを意味します INDEXでも、暗黙的に位置xが必要であることを意味します 表にあります。
ただし、INDEXがクラスター化されていない場合、INDEXはルックアップを提供するだけです。効果的に位置x INDEXの位置yに対応します 表にあります。
ここで重要なのは、INDEXで指定されていないフィールドにアクセスするときです。そうすることは、データを取得するために実際にTABLEに移動する必要があることを意味します。 CLUSTERED INDEXの場合、すでにそこにいるので、そのフィールドを見つけるオーバーヘッドはかなり低くなります。ただし、INDEXがクラスター化されていない場合は、事実上、テーブルをINDEXに結合してから、目的のフィールドを見つける必要があります。
ノート; (id_dernier_fichier, codega)に複合インデックスを設定する (id_dernier_fichier)だけに1つのインデックスを付けるのとは大きく異なります (codega)だけの個別のインデックス 。
クエリの場合、コードを変更する必要はまったくないと思います。しかし、あなたはかもしれません インデックスを変更することでメリットが得られます。
多くにアクセスしたいとおっしゃっています 田畑。これらすべてのフィールドを複合インデックスに入れることは、おそらく最善の解決策ではありません。代わりに、(id_dernier_fichier)にクラスター化インデックスを作成することもできます。 。これは、* id_dernier_fichier *が特定されると、他のすべてのフィールドも取得するための適切な場所にいることを意味します。
13.2.10.1。クラスタ化インデックスとセカンダリインデックス
すべてのInnoDBテーブルには、行のデータが格納されるクラスター化インデックスと呼ばれる特別なインデックスがあります。
- テーブルにPRIMARYKEYを定義すると、InnoDBはそれをクラスター化インデックスとして使用します。
- テーブルにPRIMARYKEYを定義しない場合、MySQLはNOT NULL列のみを持つ最初のUNIQUEインデックスをプライマリキーとして選択し、InnoDBはそれをクラスター化インデックスとして使用します。
- テーブルにPRIMARYKEYまたは適切なUNIQUEインデックスがない場合、InnoDBは、行ID値を含む合成列に非表示のクラスター化インデックスを内部的に生成します。行は、InnoDBがそのようなテーブルの行に割り当てるIDで並べ替えられます。行IDは6バイトのフィールドであり、新しい行が挿入されると単調に増加します。したがって、行IDで順序付けられた行は、物理的に挿入順序になります。