SQL Server 2014 SAYISI (DISTINCT x), sütun x için istatistik yoğunluğu vektörünü yok sayar

Bir For COUNT(DISTINCT)sahip olduğunu ~ 1 milyar ayrı değer, ben sadece ~ 3 milyon satır olduğu tahmin karma agrega ile bir sorgu planı alıyorum.

Bu neden oluyor? SQL Server 2012 iyi bir tahmin üretir, bu yüzden bu SQL Server 2014'te Connect hakkında rapor etmem gereken bir hata mı?

Sorgu ve kötü tahmin

-- Actual rows: 1,011,719,166
-- SQL 2012 estimated rows: 1,079,130,000 (106% of actual)
-- SQL 2014 estimated rows: 2,980,240 (0.29% of actual)
SELECT COUNT(DISTINCT factCol5)
FROM BigFactTable
OPTION (RECOMPILE, QUERYTRACEON 9481) -- Include this line to use SQL 2012 CE

-- Stats for the factCol5 column show that there are ~1 billion distinct values
-- This is a good estimate, and it appears to be what the SQL 2012 CE uses
DBCC SHOW_STATISTICS (BigFactTable, _WA_Sys_00000005_24927208)
--All density   Average Length  Columns
--9.266754E-10  8               factCol5
SELECT 1 / 9.266754E-10
-- 1079126520.46229

Sorgu planı

Komut dosyasının tamamı

Burada, yalnızca bir istatistik veritabanı kullanarak durumun tam bir reprotu .

Şimdiye kadar denediklerim

İlgili sütun için istatistiklere girdim ve yoğunluk vektörünün yaklaşık ~ 1.1 milyar farklı değer gösterdiğini buldum. SQL Server 2012 bu tahmini kullanır ve iyi bir plan üretir. SQL Server 2014, şaşırtıcı bir şekilde, istatistiklerin sağladığı çok doğru tahmini görmezden geliyor ve bunun yerine çok daha düşük bir tahmin kullanıyor. Bu, neredeyse yeterince bellek ayırmayan ve tempdb'ye dökülen çok daha yavaş bir plan üretir.

İz bayrağı denedim 4199, ama bu durumu düzeltmedi. Son olarak, izleme bayraklarının bir kombinasyonu aracılığıyla optimizasyon bilgilerine girmeye çalıştım (3604, 8606, 8607, 8608, 8612). bu makalenin . Ancak, nihai çıktı ağacında görünene kadar kötü tahmini açıklayan hiçbir bilgi göremedim.

Bağlantı sorunu

Bu sorunun yanıtlarına dayanarak, bunu Connect'te bir sorun olarak da sundum

Kardinalite tahmininin elde edilme şekli kesinlikle benim için sezgisel görünüyor. Farklı sayım hesaplaması (Genişletilmiş Etkinlikler veya izleme bayrakları 2363 ve 3604 ile görüntülenebilir):

Başlığa dikkat edin. Bunun genel mantığı çok makul görünüyor (daha farklı değerler olamaz), ancak kapak örneklenmiş çok sütunlu istatistiklerden uygulanır:

DBCC SHOW_STATISTICS 
    (BigFactTable, [PK_BigFactTable])
WITH
    STAT_HEADER, 
    DENSITY_VECTOR;

Bu, 3.435.431.721'den 3.35544E-07 Col5 seviyesinde bir yoğunluk vektörü ile örneklenmiş 2.980.235 satırı göstermektedir. Bunun tersi, gerçek matematik kullanılarak 2.980.240'a yuvarlanmış bir dizi farklı 2.980.235 değer verir.

Şimdi soru, örneklenmiş istatistikler göz önüne alındığında, modelin farklı değerlerin sayısı hakkında ne yapması gerektiği. Ben tahmin etmek istiyorum, ama bu yapılmadı, ve belki de kasten.

Daha sezgisel olarak, çok sütunlu istatistikleri kullanmak yerine, Col5'teki yoğunluğa bakacağını beklerdim (ama değil):

DBCC SHOW_STATISTICS 
    (BigFactTable, [_WA_Sys_00000005_24927208])
WITH
    STAT_HEADER, 
    DENSITY_VECTOR;

Burada yoğunluk 9.266754E-10, karşılıklı olan bir 1079126528 .

Bu arada açık bir çözüm, çok sütunlu istatistikleri tam tarama ile güncellemektir. Diğeri ise orijinal kardinalite tahmincisini kullanmaktır.

Açtığınız Connect öğesi olan SQL 2014 örneklenmiş çok sütunlu istatistikler, önde olmayan sütunlar için daha doğru tek sütunlu istatistikleri geçersiz kılar , SQL Server 2017 için Sabit olarak işaretlenir .