私は最近、SQLiteに適切なインデックスを与えることで、複雑なクエリを何桁も高速化しました。このような結果は、JOINやORDER BY節によく使われる他の多くのフィールドにインデックスを付けるべきかどうか疑問に思います。しかし、私は過度に欲しくないし、私に逆行したくない：私はインデックスを作成するにはいくつかの理由があるはずだと仮定するか、すべてのフィールドがデフォルトでインデックスされるだろう。多くのインデックスを持つことの短所は何ですか？
私はこの場合SQLiteを使用していますが、もちろんDBMSにとらわれないアドバイスも歓迎します。
インデックスは、挿入と更新（ロックでは本当に深刻な問題になる可能性があります）とコストのディスク容量を低下させます。それはかなりです。
インデックスは、ディスク領域を使用して保存し、作成および保守に時間がかかります。未使用のものは何の利益も与えません。問合せの候補索引が多数ある場合、問合せに対してサーバーが「間違った」索引を選択することによって、問合せが遅くなる可能性があります。
これらの要因を使用して、インデックスが必要かどうかを判断します。
通常、使用されることのないインデックスを作成することは可能です。たとえば、2つの可能な値のみを使用して（非ヌル）フィールドのインデックスを作成すると、ほぼ確実に役に立たなくなります。
頻繁に実行される索引が可能な場合は有効な索引を使用していることを確認するために、独自のアプリケーションの問合せを説明し、必要以上の索引を作成しないようにする必要があります。
2値フィールドのインデックスは、分布が極端に不均一で、データベースが統計によってそれを知っているときに（時には）役立ちます。 –
ディスク容量のインデックスのコストは、一般的には些細です。テーブルが変更されたときにインデックスを更新するための追加書き込みのコストは、通常は中程度です。追加のロックのコストは厳しくなる可能性があります。
これは、表の読取り対書込み率と、索引を実際に使用して問合せを高速化する頻度に依存します。
ええええええええええええええええええええええええええええええええええええええええええええええ投稿日時：インデックススペースの合計がテーブルスペースの合計よりも2倍（またはそれ以上）のケースが多くありました。 – MatBailie
Demsと同意します。狭い表の場合、非クラスタ化索引は表と同等のサイズにすることができます。インデックスがテーブル自体のディスクスペースの半分を占めているとします。 6つのインデックスを持つテーブルは、インデックスされていないものと比べてディスクの4倍の大きさです。クラスタ化インデックスは基本的に無料です。 –
いいえ、ディスクスペース内のインデックスのコストは「一般的に自明」ではありません。索引で多くのスペースを使用することは可能です。 – MarkR
特定のアプリケーションをテストするには、実行するクエリの前に「EXPLAIN QUERY PLAN」と入力して結果を確認します。それは、インデックスがどこにあるのか、インデックスを使用していないのかを示します。
このようにして、より多くのインデックスを使用できる場所とどこに差異が生じないかを判断できます。私はトラブルを起こしているように見える手のテストクエリのへSqliteSpyを使用
。
それはそれをカバーします。良い挿入/更新/削除のパフォーマンスのために適切なインデックスが必要であることを忘れないでください。すべてのものと同様に、それはバランスです。 –
挿入物は索引の恩恵を受けません...更新と削除では、関連する行を見つける必要があるため、そのステップの索引の恩恵を受けますが、多くの索引が必要な場合は、あなたが言うように、それはすべてバランスです:) – MatBailie