インデックス付きの列がパフォーマンスの向上につながることを知っている場合、データベースのすべてのテーブルのすべての列にインデックスを付ける価値はありますか? そのようなアプローチの利点/欠点は何ですか?
価値がある場合、SQL Server でインデックスを自動作成する方法はありますか? 私のアプリケーションは (ユーザー構成に応じて) テーブルと列を動的に追加し、自動インデックスを作成したいと考えています。
インデックス付きの列がパフォーマンスの向上につながることを知っている場合、データベースのすべてのテーブルのすべての列にインデックスを付ける価値はありますか? そのようなアプローチの利点/欠点は何ですか?
価値がある場合、SQL Server でインデックスを自動作成する方法はありますか? 私のアプリケーションは (ユーザー構成に応じて) テーブルと列を動的に追加し、自動インデックスを作成したいと考えています。
上記の理由から、すべての列にインデックスを付けることが役立つ現実世界のシナリオを想像することは困難です。このタイプのシナリオでは、すべてテーブルの 1 つの列に正確にアクセスするさまざまなクエリが必要になります。各クエリが異なる列にアクセスしている可能性があります。
他の回答は、クエリの選択側の問題に対処していません。明らかに、インデックスを維持することは問題ですが、テーブルを一度作成してから何度も読み取る場合、更新/挿入/削除のオーバーヘッドは考慮されません。
インデックスには、元のデータと、データが存在するレコード/ページへのポイントが含まれています。インデックスの構造により、単一の値を見つける、値を順番に取得する、個別の値の数をカウントする、最小値と最大値を見つけるなどの作業が高速になります。
インデックスは、ディスクのスペースを占有するだけではありません。さらに重要なことは、メモリを占有することです。また、多くの場合、メモリの競合がクエリのパフォーマンスを決定する要因になります。一般に、すべての列にインデックスを作成すると、元のデータよりも多くのスペースが占有されます。(1 つの例外は、比較的幅が広く、値が比較的少ない列です。)
さらに、多くのクエリを満たすために、1 つ以上のインデックスと元のデータが必要になる場合があります。ページ キャッシュがデータでいっぱいになり、キャッシュ ミスの数が増える可能性があり、その結果、より多くのオーバーヘッドが発生します。
あなたの質問は、データ構造を適切にモデル化していないことを本当に示しているのだろうか。ユーザーにアドホックの永続テーブルを作成させたい場合はほとんどありません。より一般的には、データは事前定義された形式で保存され、アクセス要件に合わせて最適化できます。
いいえ、レコードを追加または更新するたびにインデックスを再計算する必要があり、すべての列にインデックスを作成すると時間がかかり、パフォーマンスが低下することを考慮する必要があるためです。
したがって、選択クエリのみを使用するデータ ウェアハウスのようなデータベースは良い考えですが、通常のデータベースでは悪い考えです。
また、インデックスを追加する必要があるのは、where 句で列を使用しているからではありません。レコードが主キーのようにほぼすべて一意であり、頻繁に編集しない列を見つけてみてください。考えられる値は 2 つしかなく、インデックスの結果はデータを分割するだけで、ほぼすべてのレコードを検索するため、人の性別にインデックスを付けることは悪い考えです。
いいえ、すべての列にインデックスを付ける必要はありません。これにはいくつかの理由があります。
Explainプランとデータアクセスを使用し、必要に応じて(必要な場合にのみ、IMHOで)インデックスを追加する方が、すべてを事前に作成するよりもはるかに優れています。
いいえ、インデックスの維持にはオーバーヘッドがあるため、すべての列にインデックスを付けると、挿入、更新、削除のすべての操作が遅くなります。WHERE句で頻繁に参照している列にインデックスを付ける必要があります。そうすれば、メリットがわかります。
インデックスはスペースを取ります。また、作成、再構築、保守などに時間がかかります。したがって、古い列だけをインデックスに登録しても、パフォーマンスの向上が保証されるわけではありません。使用する操作のパフォーマンスを示す列にインデックスを付ける必要があります。インデックスは読み取りに役立ちます。したがって、ほとんどの場合、他のテーブルで検索、並べ替え、または結合される列にインデックスを付けます。そうでなければ、それはあなたが見るかもしれないどんな利益よりも高価です。