Yüksek seçicilik ve düşük seçicilik alanlarına sahip bileşik bir dizin düzeninde alan sırası

3 milyardan fazla satır içeren bir SQL Server tablo var. Bir benim sorgu son derece uzun zaman alır, bu yüzden onu optimize düşünüyorum. Sorgu şöyle görünür:

SELECT [Enroll_Date]
      ,Count(*) AS [Record #]
      ,Count(Distinct UserID) AS [User #]
  FROM UserTable
  GROUP BY [Enroll_Date]

[Enroll_Date], 50'den az olası değere sahip düşük seçiciliğe sahipken UserID sütunu 200 milyondan fazla farklı değere sahip yüksek seçiciliğe sahip bir sütundur. Araştırmamı temel alarak bu iki sütun üzerinde kümelenmemiş bir bileşik dizin oluşturmam gerektiğine inanıyorum ve teoride yüksek seçicilik sütunu ilk sütun olmalı. Ama benim durumumda, bu işe yarayacağından emin değilim çünkü gruptaki düşük seçicilik sütununu yan tümce olarak kullanıyorum.

Bu tablonun kümelenmiş dizini yok.

@ AaronBertrand'ın çözümüne alternatif olarak (dizine alınmış bir görünüm oluşturmak istemiyorsanız veya istemiyorsanız), üzerinde bir dizin oluşturmanızı öneririm (Enroll_Date, UserID). Bu tür bir soru tablonuzda çok yaygınsa, bu muhtemelen kümelenmiş dizininiz olmalıdır.

Genel olarak yüksek seçiciliğe sahip dizinleri genel bir "en iyi uygulama" olarak önermem, bunun yerine sorgunuza en iyi performansı hangi dizine vereceğine bakarım.

Tarihinde bir dizin, (Enroll_Date, UserID)sorgunuza Akış Toplamaları ile oldukça optimize edilmiş, engellenmeyen bir sorgu planı verecektir.

Bu bağlamda "engellenmemesi", sorgunun önemli miktarda veri (örneğin bir sıralama veya karma toplamı gibi) arabelleğe alması gerekmediği anlamına gelir. b) neredeyse hiç çalışma belleği tüketmez.

Aarons'un cevabı harika bir çözüm. Bu yaklaşımı benimsemek istemediğinizi varsayarak soruyu cevaplayacağım.

Gönderdiğiniz sorgu genellikle önce gruplandırıldıktan (Enroll_Date, UserID)sonra tekrar gruplandırılarak yürütülür (Enroll_Date). Bu optimizasyon SQL Server 2012 için yenidir COUNT DISTINCT.

Belirli bir sırayla bu iki sütundaki bir dizin, (Enroll_Date, UserID)bir dizin taramasını art arda iki Akış Topluluğuna yönlendiren etkili bir plan elde etmek için yeterli olacaktır. Tersi emir bu planı mümkün kılmaz.

Bu nedenle, siparişi kullanın (Enroll_Date, UserID). Burada baţka seçeneđin yok.

Sorgu zamanı yerine yazma zamanında hesaplamalar ve toplamalar için ödeme yapmanıza olanak tanıyan dizine alınmış bir görünüm için ideal bir senaryo gibi görünür.

CREATE VIEW dbo.MyIndexedView
WITH SCHEMABINDING
AS 
  SELECT Enroll_Date, UserID, RawCount = COUNT_BIG(*)
  FROM dbo.UserTable
  GROUP BY Enroll_Date, UserID;
GO

CREATE UNIQUE CLUSTERED INDEX CIX_miv ON dbo.MyIndexedView(Enroll_Date, UserID);

Bunun oluşturulması biraz zaman alacak ve elbette, temel tablodaki bir dizin gibi, tüm DML işlemlerinde bakım gerektirecektir.

Şimdi bu görünüme karşı sorgu oldukça benzer olacaktır - görünümdeki her satır şimdi ayrı bir kullanıcı / tarih kombinasyonunu temsil eder, böylece bu sayı tek bir COUNT (*) ile hesaplanabilirken, temel tablodaki toplam satır sayısı zaten sizin için kısmen toplanmıştır, şimdi bunları tarih başına SUM kullanarak eklemeniz yeterlidir:

SELECT Enroll_Date, 
  [Record #] = SUM(RawCount),
  [User #] = COUNT(*)
FROM dbo.MyIndexedView WITH (NOEXPAND)
GROUP BY Enroll_Date; 

Bunu ve bunu hatırladıktan sonra NOEXPAND ipucu eklendi .

Hiç şüphesiz bu sorgunun her bir sorgu için tam olarak bir kullanıcınızın olduğu nadir durumlarda (bu durumda aynı miktarda veri olacaktır) okunacak) ve bildiğimiz sütunlar temel tablonun dizinindeki tek sütunlardır. Okuma zamanındaki performans artışının, iş yükünüzün yazma kısmını etkileyecek ekstra çalışmaya değip değmeyeceği, size söyleyemeyeceğimiz bir şeydir - ödünleşimi ölçmek için test etmeniz gerekir (hiçbir dizin ücretsiz değildir).

Ayrıca, belirli, iyi tanımlanmış aralıklar (örneğin, geçerli çeyrek veya bugüne kadar) için Enroll_Date'e karşı aynı ortak WHERE yan tümcelerini sık sık kullanıyorsanız, G / Ç'yi daha da azaltan eşleşen filtrelenmiş dizinler ekleyebilirsiniz (ancak her zaman Pazarlıksız).

Ayrıca temel tabloya kümelenmiş bir dizin koymayı düşünebilirsiniz. Bu, bir yığından yararlanan çok nadir kullanım durumlarından biri gibi görünmüyor.