テーブルのインデックス作成のベストプラクティスをよりよく理解する
考慮すべきいくつかの基準があるときに、テーブルのインデックス作成をいつ開始するかは完全にはわかりません。
- テーブルはそれほど大きくないと思います（1000-10,000行）。
- 検索はCMS管理ページから行われるため、フロントエンドよりも多くの種類のフィルタリング/並べ替えオプション/組み合わせが含まれます。
- インデックスを追加しすぎると、検索が速くなる可能性がありますが、テーブルへのデータの挿入/更新のパフォーマンスに劇的に影響するか、またはDBエンジンクエリに対して間違ったインデックスを選択します。
- テキスト検索に関しては、
Fulltextインデックスを追加しています。 - 列に基づいた並べ替え/フィルタリングに関して、より良いパフォーマンスが得られると信じるために、
DATETIME/INT/BIGINTのasc/descインデックスも追加しています。
上記のパラメーターを考慮すると、インデックスを追加してアプリのパフォーマンスを向上させるのに最適なポイントが何であるか、そして「インデックスナチ」になる傾向があります（フランス語を許してください）-考えられるあらゆるシナリオに対して、ますます多くのインデックスを追加していることに気づきました。
この質問が広すぎないことを願っています。例を含めなかったのは、インデックス作成に関しては、良い習慣と悪い習慣のより一般的な動作だからです。
インデックスをランダムに追加しないでください。クエリを見て、必要なインデックスを決定します。 my cookbook を参照してください。
InnoDBは本当に_PRIMARY KEY_を必要とします。 PKはインデックスであり、UNIQUEであり、クラスター化されていることに注意してください。そのため、同じ列で始まるインデックスを追加しないでください。
_WHERE a=2 AND b=4_は、「複合」インデックスを要求します：INDEX(a,b)またはINDEX(b,a)。これらは、2つの個別のインデックスINDEX(a), INDEX(b)とは異なります。
本当に膨大な数になると予想しない限り、BIGINTを使用しないでください。
DESCは、INDEX宣言では無視されます。ただし、それによってオプティマイザが逆の順序でインデックスを実行して「降順」の効果を得ることは停止されません。
FULLTEXTは、MATCH(...) AGAINST(...)を使用する場合にのみ役立ちます。
「多すぎる」インデックスは、一部の挿入を遅くし、UPDATEsを遅くして、インデックス付きの列を変更します。
「フラグ」にインデックスを付けないでください。このようなインデックスは使用されません。
1000行のテーブルの場合、インデックスを配置しても意味がないと思います。テーブル全体がメモリに収まるので、十分高速です。ただし、インデックスを配置する場合は、常にビジネス価値を考慮する必要があります。各インデックスがテーブルへのオーバーヘッドを生成することを考慮してください。制限がどこにあるかはわかりませんが、どの場合でも最もよく使用されるフィルターを確認し、これをインデックス作成の最初の指標として使用してください