インデックス作成の使用を開始するために、テーブルの行数に最適な数はありますか？
私はDBAの初心者です。テーブルの行に指定されたポイントがあり、そのポイントに到達したときにインデックスを使用できるかどうかを知りたい。テーブルの行数とインデックスの使用の間に依存関係があるはずですが、標準のテーブルの行数があるかどうかはわかりません。
bestについては知りませんが、少数では実際の値はありません。
インデックスの使用にはある程度のオーバーヘッドがあります。はい、インデックスシークはテーブルスキャンより高速ですが、インデックスの使用にはある程度のオーバーヘッドがあります。インデックスのメンテナンスには明らかにオーバーヘッドがあります。
テーブルにPKがある場合は、それをPKとして使用し、通常はクラスター化する必要があります。
USstatesのテーブル（50行）を考えてみます。
ID PK ID tinyint
名前varchar（20）
Region tinyint
地域は、NE、SEなどの州をグループ化するために使用されます...
私は個人的には名前や地域のインデックスを使用しません-テーブルスキャンはまだ非常に高速です。リージョンはFKになりますが、（私の理解では）インデックスが自動的に作成されるわけではありません。テーブル全体は2Kページサイズで適切です。 State.Nameでの並べ替えが頻繁に使用される場合は、そのインデックスが使用されますが、パフォーマンスの向上を測定することさえできないと思います。
100万行を超えると、前もってインデックスの作成が始まります。
1000から100万の間は、ケースバイケースでインデックスを構築することを検討してください。
10,000行でも、明らかなインデックスのケースが多数発生します。変更される可能性が低く、検索と並べ替えに頻繁に使用されるAddDateのような列です。 StateをFKとして参照する10,000行を超えるテーブルでは、その列に前もってインデックスを付けます。しかし、質問をしているので、実際のクエリを待って最適化するかもしれません。
可能性がありますを使用するため、他の極端な方法ですべての列にインデックスを付けないでください。インデックスにはオーバーヘッドがあります。インデックスは挿入と更新を遅くします。高度にフラグメント化されたインデックスは、テーブルスキャンよりも遅くなる可能性があります。
このサイトのユーザーの多くは、事前に最適化し、理論的な議論をしたいと考えています。これは、DBAの初心者向けの実際のアドバイスです。
インデックスは、テーブルまたはビューに関連付けられたディスク上の構造であり、テーブルまたはビューからの行の取得を高速化します。インデックスには、テーブルまたはビューの1つ以上の列から構築されたキーが含まれます。これらのキーは、SQL Serverがキー値に関連付けられた1つまたは複数の行をすばやく効率的に検索できるようにする構造（Bツリー）に格納されます。
テーブルの行に指定されたポイントがあり、そのポイントに到達したときにインデックスを使用できるかどうかを知りたい。
テーブルの行数はインデックスの使用を指示しません。データの検索が可能な限り高速になるように、インデックスを作成する必要性を示すクエリ（パターン）。
クエリオプティマイザーは、統計に基づいて最適なクエリプランを作成します。
From SQL Serverインデックスデザインガイド ：
データベースとそのワークロードに適切なインデックスを選択することは、クエリ速度と更新コストの間の複雑なバランス処理です。
狭いインデックス、またはインデックスキーの列が少ないインデックスでは、必要なディスク領域とメンテナンスのオーバーヘッドが少なくなります。
一方、ワイドインデックスは、より多くのクエリをカバーします。最も効率的なインデックスを見つける前に、いくつかの異なるデザインを試す必要がある場合があります。データベーススキーマやアプリケーションの設計に影響を与えることなく、インデックスを追加、変更、および削除できます。
SQL ServerのDMVを使用してインデックス作成戦略を調整する を使用するか、または sp_BlitzIndex を使用して、より多くの洞察を得る必要があります。
参照する ：
インデックスは確かにデータを見つけるのに役立ちます。そのため、小さなテーブルにインデックスを付けないことを選択できます。また、データの品質にも影響を与えます。たとえば、値がテーブル内の多くても1つの行で発生するようにするには、一意のインデックスを使用できます。これらのロールでは、テーブルの行数に関係なく、インデックスを定義する必要があります。
インデックスを使用しない理由はありません。
テーブルが小さい場合、インデックスアクセスもコストに関連付けられているため、シーケンシャルスキャンの方がインデックススキャンよりもオーバーヘッドが少なく、テーブルデータへのランダムアクセスが続くため、コスト見積もりは簡単に推測できます。ランダムアクセスよりもコストがかかります。
唯一の欠点は、それがINSERTを遅くすることです-しかし、それが懸念される場合は、多くの行を作成することになります。
他の人が言ったように、行数はガイドではありません。システムに一般的なクエリを見つけ、ioをオンにしてSSMSで実行します。
set statistics io on;
select * from SomeTable order by SomeColumn;
「論理読み取り」カウンターの「メッセージ」タブを見てください。これは、クエリを満たすために読み取る必要があるページの数です。 （「論理的」とは、ページがすでにメモリ内にある場合、変更されないことを意味します。）
それが低い場合（たとえば、1つの数値で）、インデックスは役に立たない可能性があります。テストデータベースがある場合は、インデックス付きとインデックスなしの両方で試してください。