考慮すべきいくつかの基準があるときに、テーブルのインデックス作成をいつ開始するかは完全にはわかりません。
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行のテーブルの場合、インデックスを配置しても意味がないと思います。テーブル全体がメモリに収まるので、十分高速です。ただし、インデックスを配置する場合は、常にビジネス価値を考慮する必要があります。各インデックスがテーブルへのオーバーヘッドを生成することを考慮してください。制限がどこにあるかはわかりませんが、どの場合でも最もよく使用されるフィルターを確認し、これをインデックス作成の最初の指標として使用してください