Bitmap filtreleriyle sorgu planlarının okunması bazen zor olabilir. Gönderen yeniden bölme akışları için BOL makalesinde (vurgu benim):
Repartition Streams operatörü birden fazla akış tüketir ve birden fazla kayıt akışı üretir. Kayıt içeriği ve biçimi değiştirilmez. Sorgu iyileştirici bir bitmap filtresi kullanıyorsa, çıkış akışındaki satır sayısı azalır.
Ayrıca , bitmap filtreleriyle ilgili bir makale de yararlıdır:
Bitmap filtrelemesi içeren bir yürütme planını analiz ederken, verilerin plandan nasıl aktığını ve filtrelemenin nerede uygulandığını anlamak önemlidir. Bitmap filtresi ve optimize edilmiş bitmap, karma birleştirmenin oluşturma girdisi (boyut tablosu) tarafında oluşturulur; bununla birlikte, gerçek filtreleme tipik olarak karma birleştirmenin prob girişi (olgu tablosu) tarafında bulunan Paralellik operatörü içinde yapılır. Ancak, bitmap filtresi bir tamsayı sütununu temel aldığında, filtre Paralellik işleci yerine doğrudan ilk tabloya veya dizin tarama işlemine uygulanabilir. Bu tekniğe sıralı optimizasyon denir.
Sorgunuzla gözlemlediğiniz şeyin bu olduğuna inanıyorum. Bitmap operatörü IN_ROWolgu tablosuna karşı olsa bile, bir kardinalite tahminini azaltan bir yeniden bölümleme akışı operatörü göstermek için nispeten basit bir demo bulmak mümkündür . Veri hazırlama:
create table outer_tbl (ID BIGINT NOT NULL);
INSERT INTO outer_tbl WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;
create table inner_tbl_1 (ID BIGINT NULL);
create table inner_tbl_2 (ID BIGINT NULL);
INSERT INTO inner_tbl_1 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
INSERT INTO inner_tbl_2 WITH (TABLOCK)
SELECT (ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) / 2000000 - 2) NUM
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;
İşte çalıştırmamanız gereken bir sorgu:
SELECT *
FROM outer_tbl o
INNER JOIN inner_tbl_1 i ON o.ID = i.ID
INNER JOIN inner_tbl_2 i2 ON o.ID = i2.ID
OPTION (HASH JOIN, QUERYTRACEON 9481, QUERYTRACEON 8649);
Planı yükledim . Aşağıdaki operatöre bir göz atın inner_tbl_2:
İkinci testi Paul White tarafından Nullable Columns'taki Hash Joins'te de faydalı bulabilirsiniz.
Satır azaltmanın nasıl uygulandığı konusunda bazı tutarsızlıklar vardır. Ben sadece en az üç tablo ile bir plan görmek mümkün. Ancak, doğru veri dağıtımında beklenen satırlardaki azalma makul görünmektedir. Olgu tablosundaki birleştirilmiş sütunun, boyut tablosunda bulunmayan birçok tekrarlanan değere sahip olduğunu varsayalım. Bir bitmap filtresi, birleştirmeye ulaşmadan önce bu satırları kaldırabilir. Sorgunuz için tahmin 1'e kadar azaltılır. Satırların karma işlevi arasında nasıl dağıtıldığı iyi bir ipucu sağlar:
Buna dayanarak, Object1.Column21sütun için tekrarlanan birçok değer olduğundan şüpheleniyorum . Tekrarlanan sütunlar için istatistik histogramında olmazsa Object4.Column19SQL Server kardinalite tahmin çok yanlış alabilir.
Sorgunun performansını artırmak mümkün olabileceğinden endişelenmeniz gerektiğini düşünüyorum. Tabii ki, sorgu yanıt süresi veya SLA gereksinimlerini karşılıyorsa, daha fazla araştırmaya değmeyebilir. Ancak, daha fazla araştırma yapmak isterseniz, sorgu iyileştiricinin daha iyi bilgi içeriyorsa daha iyi bir plan seçip seçmeyeceği hakkında bir fikir edinmek için yapabileceğiniz birkaç şey vardır (istatistikleri güncellemek dışında). Arasında birleştirme Sen sonuçlarını koyabilirsiniz Database1.Schema1.Object10ve Database1.Schema1.Object11geçici tabloya ve iç içe geçmiş bir döngü birleştirmeler almaya devam olmadığını görmek. LEFT OUTER JOINSorgu optimize edicinin bu adımdaki satır sayısını azaltmaması için bu birleşimi bir şekilde değiştirebilirsiniz . MAXDOP 1Ne olduğunu görmek için sorgunuza bir ipucu ekleyebilirsiniz . KullanabilirsinTOPbirleşmeyi son gitmeye zorlamak için türetilmiş bir tabloyla birlikte, hatta sorguyu birleştirmeyi bile yorumlayabilirsiniz. Umarım bu öneriler başlamanız için yeterlidir.
Sorudaki bağlantı öğesi ile ilgili olarak, sorunuzla ilgili olması muhtemel değildir. Bu sorunun kötü satır tahminleri ile bir ilgisi yoktur. Sahne arkasındaki sorgu planında çok fazla satırın işlenmesine neden olan bir paralellik koşulu ile ilgilidir. Burada sorgunuz ekstra bir iş yapmıyor gibi görünüyor.
