最初に注意する必要があるのは、MySQLはpsuedo-SELECT（ステートメントではない）ごとに1つのインデックスのみを使用することです。EXPLAINを使用してSELECTの出力を表示すると、どのインデックスが選択されたかがわかります。 EXPLAINはSELECTSでのみ実行できるため、SELECTの構文を交換するときは、DELETE/UPDATEが同じプランを使用していると想定する必要があります...
私の知る限り、ほとんどのデータベース（埋め込まれているデータベースは奇妙な場合があります）は、次の句でのインデックスの使用をサポートしています。
- SELECT
- JOIN（ANSI-92構文）
- 場所（ANSI-89との両方があるため ここでのフィルタリング）
- HAVING（WHEREと同等ですが、WHEREとは異なり、サブクエリを必要とせずに集計を使用できます）
- 注文者
私はGROUPBYを100％使用しているわけではないので、当面は省略します。
最終的には、アルゴリズムと手元にある統計に基づいて、何を使用するかをオプティマイザーが選択します。 ANALYZETABLE構文 を使用できます。 統計を更新します（定期的に、常にではありません）。
補遺
MySQLは、インデックスを割り当てるためのスペースの量も制限します- 1,000 MyISAMテーブルの場合はバイト、InnoDBテーブルの場合は767バイト 。 MySQLはpsuedo-SELECTごとに1つのインデックスしか使用しないため、インデックス（複数の列を含むインデックス）をカバーすることは良い考えですが、最も一般的なクエリをテストし、可能な限り最適化することになります。インデックス作成の優先順位は次のとおりです。
- 主キー（v5のどこかで、pkのインデックス作成が自動化されました）
- 外部キー（次に最も可能性の高いJOIN候補
- ろ過基準（スペースがあると仮定）