どの時点でインデックスが効率的になるか

テーブルにインデックスを追加すると検索が高速になり、挿入が遅くなるが、テーブルが大きい場合に限られると多くのリソースが見つかりました。これにより、設計上の決定であるトレードオフが生じますが、インデックスの使用が不合理になる前に、おおよそのテーブルサイズが必要です。（たとえば、10行はおそらくその制限をはるかに下回ります）

この制限がどこにあるか、または私を正しい方向に向けるリソースを知っている人はいますか？

正確な制限を前もって決定することは本当に難しいです。

ほとんどの人が過小評価していることの1つは、インデックスがクエリで使用される候補になる前に、インデックスが満たさなければならない高い要件です。

効率的な（非クラスター化）インデックス

• 優れた選択性を提供します。たとえば、行全体の非常に小さいパーセンテージ（<1％、<2％）のみを返します。選択性が指定されていない場合-SQL Serverのクエリオプティマイザーはこのインデックスを無視する可能性が高い

• 理想的にはクエリをカバーする必要があります。つまり、クエリに必要なすべての列を返します。1つまたは2つのインデックス列があり、含まれる列として別の（2-4）列を含むインデックスを作成でき、クエリをカバーできる場合、クエリオプティマイザーがこのインデックスを使用する可能性があります。つまり、コードが常にすべての列SELECT * .....をフェッチするために使用している場合、インデックスが使用される可能性は低くなります-実際には、

他にもたくさんの基準があると思いますが、これらの2つが最も重要な基準だと思います。もちろん、常にインデックスを適切に維持（再編成、再構築）し、インデックスに関連付けられた統計が最新であることを確認する必要があります。

PS：外部キー列の非クラスター化インデックスは特殊なケースです。デフォルトでは、参照整合性チェックとJOINそれらのFK制約の両方を高速化するのに役立つため、常にこれらを追加することをお勧めします。しかし、ここでも、FK列のインデックスを "拡張"して、 "include"列を追加してさらに便利にすることは絶対に有効です。

10行しかないインデックスから改善が見られる場合があります。

私のマシンでの次のテストでは、インデックスのないバージョンが10.5数秒で完了し、インデックスのあるバージョンが数秒で完了しました9.8（3回以上の実行で一貫性があります）。

この場合のインデックスは1つのリーフページのみで構成されていますが、スロット配列はインデックスキーの順序で並べられているため、SQL Serverは、10個すべての集計を実行するのではなく、対象の単一の行を返すことができます。

CREATE TABLE T
(
X INT,
Y CHAR(100) NULL
)

INSERT INTO T (X)
SELECT number 
FROM master..spt_values
WHERE type='P' AND number BETWEEN 1 AND 10

set nocount on;

DECLARE @I INT, @X INT

DECLARE @Time DATETIME2(7) = SYSUTCDATETIME()

SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

CREATE CLUSTERED INDEX IX ON T(X)
SET @Time = SYSUTCDATETIME()
SET @I = 1
    WHILE (@I < 1000000)
    BEGIN
    SELECT @X = MAX(X)
    FROM T
    SET @I += 1
    END

SELECT DATEDIFF(MICROSECOND, @Time, SYSUTCDATETIME())

DROP TABLE T