Bir dizin mi yoksa iki dizin mi?

Veritabanımdaki bir tabloda aşağıdaki dizin oluşturuldu:

CREATE INDEX [idx_index1]
on [table1]
(col1, col2, col3)

Sunucu aşağıdaki 'eksik' dizini öneriyor:

CREATE INDEX [idx_index2]
on [table1]
(col1, col2)
INCLUDE (col3, col4, col5, col6....)

Korunması gereken yeni bir dizin oluşturmak yerine, mevcut dizin tanımını önerilen sütunları içerecek şekilde değiştirmek bana mantıklı geliyor. Col1 ve col2 üzerinde seçilen bir sorgu index1'i index2 kadar etkili bir şekilde kullanabilir. Doğru muyum yoksa bir şey mi kaçırıyorum?

Ve böylece performans ayarlama ve indeksleme stratejileri sanatına giriyor ...

Mevcut sütun tanımını önerilen sütunları içerecek şekilde değiştirmek bana mantıklı geliyor

Teklifinizi alıp üçüncü bir indeks tanımı yazacağım:

create index [idx_index3]
on [table1] (col1, col2, col3)
include (col4, col5, col6....);

CREATE INDEXAlıntıladığınız ifadeye karşılık gelen ifade bu olmalıdır .

Bu çok iyi bir ihtiyatlı çözüm olabilir, ancak duruma göre değişir . İşte buna bağlı olduğunu söylediğimde birkaç örnek.

Çoğunlukla böyle sorgulardan oluşan ortak bir iş yükünüz varsa:

select col1, col2, col3
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

O zaman idx_index1endeksiniz sağlam olur. Mükemmel bir şekilde dar ise, bu sorguyu içinde fazla veri bulunmayan bir dizindir (eğer varsa, kümelenmiş dizin tanımını dikkate almaz).

Ancak, esas olarak aşağıdaki gibi sorgulardan oluşan iş yükünüz varsa:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2;

Öyleyse , kümelenmiş dizine (veya yığına bir RID aramasına) anahtar aramaya olan ihtiyacı engelleyen idx_index2bir kaplama dizini olarak adlandırılan akıllıca olacaktır . Kümelenmemiş dizin tanımı yalnızca sorgulama gerektiren tüm verileri kapsar.

Tavsiyenizle, aşağıdaki gibi bir sorgu için çok uygun olacaktır:

select co11, col2, col3, col4, col5
from table1
where col1 = 1
and col2 = 2
and col3 = 3;

Tavsiyeniz idx_index3, yukarıdaki sorgu için arama ölçütlerini karşılayan bir kaplama dizini olacaktır.

Ulaşmaya çalıştığım nokta, bunun gibi izole bir soruda, buna kesin olarak cevap veremeyiz. Her şey ortak ve sık iş yükünün ne olduğuna bağlıdır. Tabii ki her bir örnek sorgu türünü işlemek için her zaman bu dizinlerin üçünü de tanımlayabilirsiniz, ancak daha sonra bu dizinleri güncel tutmak için gerekli olan bakım söz konusudur (düşünün: INSERTs, UPDATEs, DELETEs). Dizinlerin yükü budur.

İş yükünü incelemeniz ve değerlendirmeniz ve avantajların nerede en iyi olacağını belirlemeniz gerekir. İlk örnek sorgusu, saniyede düzinelerce kez yapılan en yaygın soruysa ve üçüncü örnek sorgusu gibi çok seyrek bir sorgu varsa, dizinin yaprak düzeyi sayfalarını INCLUDEanahtar olmayan sütunlar. Her şey iş yükünüze bağlıdır.

İhtiyatlı endeksleme stratejilerini ve ortak iş yükünüzü anlarsanız, her ikisini de uygulayarak en iyi yolun ne olduğunu öğrenebilirsiniz.

Gerçekten haklısınız ve bir DBA'nın eksik dizin DMV'leri tarafından öne sürülen "önerileri" her zaman gözden geçirmesinin neden önemli olduğunu keşfettiniz .

Eksik dizin DMV'leri tarafından sunulan önerilerin ayrı ayrı sunulduğunu düşünün, bu da SQL Server'ın, diğer dizin yapılarının zaten mevcut olup olmadığına bakılmaksızın, önerilen yapının bir dizininin sorguya fayda sağlayacağına karar verdiğini düşünün.

Thomas'ın cevabının sonuçlarından biri hakkında biraz daha:

Dedi ki:

Tabii ki her bir örnek sorgu türünü işlemek için her zaman bu dizinlerin üçünü de tanımlayabilirsiniz, ancak daha sonra bu dizinleri güncel tutmak için gerekli olan bakım söz konusudur (düşünün: INSERTs, UPDATEs, DELETEs). Dizinlerin yükü budur.

Yani, başka bir büyük soru şu olur: tablo ne sıklıkla güncellenir?

İlk olarak, sürekli güncellenen bir tablonun örneğini düşünün , örneğin, ORDERSweb sitesi tüketici etkinliğini yansıtan bir perakende tablo ... orada, birden fazla dizin sahibi olmak konusunda vicdanlı olmak istiyorsunuz, çünkü sürekli güncellemelerle yapılan işi arttırıyorlar ve bu nedenle veritabanının performansını sürekli etkiler.

Masa güncellenmektedir - Öte yandan, yalnızca web sitesi kurulumu bir parçası olarak güncellenir bir tablo düşünün KEZ çoğu değerleri için ve değerler seyrek eklendi -, güncelleme yavaşlamalar hemen hemen orada değil bir göz. Birden çok dizin, veritabanı dizini yeniden oluşturma ve yeniden oluşturma işlemlerini yavaşlatabilir, ancak yeterince hızlı oldukları sürece, HİÇBİR ÜCRETSİZ: birden çok dizin okumaları hızlandırırsa, devam edin.

Ortadaki bir durum normalde yalnızca bir toplu işlemde gece boyunca güncellenen bir tablo olabilir. Orada, birden fazla dizinden güncelleme yavaşlamaları gündüz performansını etkilemez - sadece (1) bu gece toplu bakımını çalıştırmak, (2) eşzamanlı işlemlerin performansını ve (3) dizin yeniden düzenleme gibi veritabanı bakım görevleri. Yani, bu 3 arenadaki süreçler sizin için yeterince hızlı çalıştığı sürece ... sorguları hızlandıran dizinler oluşturun.

HTH ...