MySQLのクエリは非常に遅い

Question

私は自分のデータベースで次のクエリを実行します。私が次のようなクエリを修正した場合：

SELECT e.codega 
FROM Enfants e JOIN FichiersEnfants f 
ON e.id_dernier_fichier = f.id_fichier_enfant 

クエリが非常に遅くなる！問題は、テーブルeとfで多くの列を選択したいのです。クエリには最大1分かかることがあります。私は別の修正を試みたが、何も働かない。 e.codegaでもid_ *のインデックスがあります。 Enfantsには9000行、FichiersEnfantsには20000行があります。助言がありますか ？ここで

情報（申し訳ありません、最初からそれらを示したず）を尋ねられます：

Answer 1

パフォーマンスの違いはおそらく原因であることe.id_dernier_fichierからですJOINに使用されるインデックスはe.codegaではありませんその index。

両方のテーブルとそのすべてのインデックスを完全に定義していないと、確実に伝えることができません。また、2つのクエリの2つのEXPLAIN PLANを含めると役立ちます。 INDEXがクラスタ化されている場合

今のところ、しかし、私は（これはまた、主キーに適用されます）...物事のカップルに

を詳しく説明することができ、データが実際に物理的に格納されますINDEXの順序これは知っているあなたにも暗黙的には、あなたがテーブルに位置のxを望む意味INDEXで位置のxを望んでいることを意味します。

INDEXがクラスタ化されていない場合、INDEXは単に参照を提供しています。インデックス内の位置xを効果的にポジションyと表記しています。

INDEXで指定されていないフィールドにアクセスするときの重要性があります。そうすることは、データを取得するために実際にTABLEに行く必要があることを意味します。 CLUSTERED INDEXの場合、既にそこにいるので、そのフィールドを見つけるオーバーヘッドはかなり低いです。 INDEXがクラスタ化されていない場合は、しかし、あなたはeffectifvely INDEXにTABLEを参加する必要があり、その後、あなたが興味のある分野を見つけ

注意。 (id_dernier_fichier, codega)にコンポジットインデックスを持つことは、ただ1つのインデックスを(id_dernier_fichier)に、別のインデックスをちょうど(codega)にすることとは非常に異なります。クエリの場合

、私はあなたがすべてでコードを変更する必要はないと思います。しかし、あなたはがインデックスを変更することによって利益を得ることができます。

フィールドにアクセスしたいとお伝えします。すべてのフィールドを複合インデックスに入れることは、おそらく最良の解決策ではありません。代わりに、(id_dernier_fichier)にCLUSTERED INDEXを作成することができます。これは、* id_dernier_fichier *が見つかると既に他のフィールドもすべて取得できることを意味します。

EDITNote About MySQL and CLUSTERED INDEXes

13.2.10.1。クラスタ化およびセカンダリインデックスは

すべてのInnoDBテーブルには、特別なインデックスは、行のデータが格納されているクラスタ化インデックスと呼ばれています：あなたがあなたのテーブルにPRIMARY KEYを定義する場合、InnoDBはクラスタ化されたとして、それを使用しています

• をインデックス。
• テーブルにPRIMARY KEYを定義しない場合、MySQLはNOT NULLカラムのみをプライマリキーとして持つ最初のUNIQUEインデックスを選択し、InnoDBはそれをクラスタ化インデックスとして使用します。
• テーブルにPRIMARY KEYまたは適切なUNIQUEインデックスがない場合、InnoDBは内部的に行ID値を含む合成列に非表示のクラスタ化インデックスを生成します。行は、InnoDBがそのようなテーブルの行に割り当てるIDによって順序付けられます。行IDは、新しい行が挿入されると単調に増加する6バイトのフィールドです。したがって、行IDによって順序付けられた行は物理的に挿入順になります。