Bir Endekse Sahip Olmanın Ne Zaman Etkin Olduğu

Bir tabloya dizin eklemenin aramaları daha hızlı hale getirdiğini ve daha yavaş eklediğini belirten birçok kaynak buldum, ancak yalnızca tablo büyükse. Bu, bir tasarım kararı olan bir ödünleşime neden olur, ancak bir dizinin kullanılmasının saçma olduğu yaklaşık bir tablo boyutu olmalıdır. (Örneğin, 10 satır muhtemelen bu sınırın çok altındadır)

Herkes bu sınırın nerede olacağını veya beni doğru yöne yönlendirecek bir kaynağı biliyor mu?

Kesin sınırı önceden belirlemek gerçekten zor.

Çoğu insanın hafife aldığı bir şey, bir dizinde sorguda kullanılacak bir aday haline gelmeden önce yerine getirmesi gereken yüksek gereksinimlerdir.

Verimli (kümelenmemiş) bir dizin

• mükemmel seçicilik sunar , örneğin toplam satırların yalnızca çok küçük bir yüzdesini (<% 1, <% 2) döndürür. Seçicilik verilmiyorsa - SQL Server'ın sorgu iyileştiricisi büyük olasılıkla bu dizini yok sayar

• ideal olarak sorguyu kapsamalı , yani sorgunun gerektirdiği tüm sütunları döndürmelidir. 1 veya 2 dizin sütununa sahip bir dizin oluşturabilir ve eklenen sütunlar olarak başka bir avuç (2-4) sütun ekleyebilir ve böylece bir sorguyu kapatabilirsiniz - o zaman sorgu optimizer'ın bu dizini kullanma olasılığı vardır. Bu ayrıca şu anlama gelir: Kodunuz her zaman tüm sütunlarıSELECT * ..... getirmek için kullanılıyorsa, endekslerin kullanılma olasılığı azalır - oldukça dramatik bir şekilde, aslında

Eminim bir ton başka kriter daha var - ama bu ikisinin en kritik olanlar olduğuna inanıyorum. Tabii ki, endekslerinizi her zaman düzgün bir şekilde muhafaza etmeli (yeniden organize etmeli, yeniden inşa etmeli) ve endekslerinizle ilişkili istatistiklerin güncel olduğundan emin olmalısınız.

Not: yabancı anahtar sütunlarındaki kümelenmemiş endeksler özel bir durumdur; Varsayılan olarak, her zaman bunları eklemeyi öneriyorum, çünkü hem referans bütünlük kontrollerini hem de JOINbu FK kısıtlamalarını hızlandırmaya yardımcı oluyorlar . Ancak burada bile, daha da kullanışlı hale getirmek için bazı ek "dahil" sütunları ekleyerek bu FK sütun indekslerini "genişletmek" kesinlikle geçerlidir.

Yalnızca 10 satırlı bir dizinden bir iyileştirme görebilirsiniz.

Aşağıdaki testte makinemde indekssiz versiyon 10.5saniyeler içinde tamamlandı ve saniyeler içinde bir indeksli versiyon 9.8(3 çalışmada tutarlı).

Bu durumda dizin yalnızca 1 yaprak sayfasından oluşur, ancak yuva dizini dizin anahtar sırasına göre sıralandığından, varlığı SQL Server'ın 10'un üzerinde bir toplama yapmak yerine yalnızca tek bir ilgi alanı döndürmesine izin verir.

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