Eksik indeksleri kör bir şekilde eklemeniz uygun mudur?

Yavaş yavaş saklı yordamlarımı eksik dizinler için sınamak için sık sık SSMS kullanıyorum. Ne zaman bir "Kayıp İndeks (Impact xxx)" görsem, diz çökme tepkim sadece yeni indeks oluşturmaktır. Bu, söyleyebildiğim kadarıyla her seferinde daha hızlı bir sorgulama ile sonuçlanıyor.

Bunu yapmaya devam etmemem için herhangi bir sebep var mı?

Birçok sebep var.

Aklıma gelen en büyüklerden biri, eksik endeksli DMV'lerin mevcut endeksleri dikkate almamasıdır.

Örnek:

Bir masan var ColA, ColB, ColC.

Şu anda bir dizin var ColA. Eksik dizin olan DMV, bir dizin eklemenizi önerecektir (ColA, ColB). Bu doğru olabilir, fakat yapılacak akıllı şey ColBmevcut dizine ikinci bir anahtar olarak eklemektir . Aksi halde kopya kapsamınız boşa gider ve boşa harcar ve giderler.

Benzer şekilde, üzerinde bir dizin varsa, üzerinde ColB INCLUDE (ColA)bir dizin önerebilir ColB INCLUDE (ColC). Yine yapılacak akıllı şey ColC, mevcut dizindeki içerme listesine eklemektir .

Önerilen dizinler çok dar bir görünüme sahiptir - yalnızca tek bir sorguya veya tek bir sorguda tek bir işleme bakarlar. Zaten var olanı veya diğer sorgulama kalıplarınızı dikkate almazlar.

Genel endeksleme stratejisini analiz etmek ve yapının verimli ve tutarlı olmasını sağlamak için hala düşünen bir insana ihtiyacınız var.

Önerilen tüm endekslerin eklenmesiyle ilgili herhangi bir sorun olmasaydı, o zaman önerilmelerine bile gerek kalmayacaktı - otomatik olarak uygulanacaklardı.

Sorgu planları tarafından açılan eksik dizin önerilerini sürekli olarak daha az güvenilir bulduklarından ve DB şemaları giderek daha karmaşık hale geldiğinden, bu ayarlama tekniğinin dikkatli kullanılmasını öneririm. Bu deneyimimdeki çeşitli nedenlerden dolayı olmuştur:

1) "Yüzde iyileştirme", en basit sorgular / en belirgin endeksler hariç herkes için bir yol olabilir, sonuçta bu yalnızca bir tahmindir ve sorgu çalıştığında gerçekleşen fiili masraflardan veya gerçek satır sayısından kaynaklanmaz. Önerilen bir dizini uyguladıktan sonra sorgu maliyetlerinin arttığını gördüm, ancak kullanılmıyor ve plan aynı kalıyor.

2) Sorgu planının kendisi ya sorgunun yapılışı nedeniyle (birleşme ve yan tümcenin optimize edilmediği vb.) Ya da eksik / güncel olmayan istatistikler nedeniyle satır sayısı tahminleri nedeniyle uygun değildir. Acımasızca kötü bir sorgu planına indekslemek, en iyi ihtimalle sadece performansta artan bir iyileşme ile bir yara bandı çözümdür.

3) Tüm resmi göremiyor olabilirsiniz. Bu, sadece grafik plan kullanılırken ve birden fazla eksik indeks önerilip önerilmediğini görmek için XML'i görüntülememek için geçerlidir. İlk önce grafik planında gösterilen, sorgu üzerinde en fazla etkiye sahip olan olmak zorunda değildir.

4) Ayrıca, mevcut dizini değiştirirken önerilecek birçok yeni dizin örneği ile karşılaştım. Bu noktaya ilişkin diğer cevapları inceleyin, açıklar, daha fazla ayrıntıya girmeme gerek yok.

Nerede daha derine bakılacağını görmek için bilinmeyen bir sorgu / ortamla çalışırken, eksik dizin önerilerini yalnızca başlangıç ​​noktası olarak kullanıyorum. Plandaki operatörlere baktığımda (çoğunlukla aramalar / taramalar / katılımlar) operatörlere baktığımda ve hangi sütunların dahil olduğunu görmek için araç ipucunu veya özellikler penceresini kontrol ederek geliştirme için test etmek üzere endeks adaylarını belirlemek için bunu kullandım.

Genelde - endekslerin nasıl çalıştığını ve depolandığını bilmek - her zaman daha iyi ya da en azından daha da kötüsü olmayan SSMS'nin önerilerini yaratacak bir indeks oluşturacaksınız.