TOP bir uygulama planını nasıl (ve neden) etkiler?

Optimize etmeye çalıştığım orta derecede karmaşık bir sorgu için, TOP nmaddeyi kaldırmanın yürütme planını değiştirdiğini fark ettim . Bir sorgu TOP nveritabanı altyapısını içerdiğinde , TOPmaddeyi yok sayarak sorguyu çalıştıracağını ve daha sonra sadece istenen sonucu n sayısı için belirlenen sonucu küçülteceğini tahmin edecektim . Grafik yürütme planı, durumun - TOP"son" adım olduğunu gösteriyor gibi görünüyor . Ama görünen o ki daha fazlası oluyor.

Sorum şu, bir TOP n cümlesi bir sorgunun uygulama planını nasıl (ve neden) etkiliyor?

İşte benim durumumda neler olup bittiğini basitleştirilmiş bir versiyonu:

Sorgu, A ve B iki tablodan satırları eşleştirmek

TOPMadde olmadan, optimizer, Tablo A'dan 19k satırlar ve Tablo B'den 46k satırlar olacağını tahmin eder. Döndürülen satırların sayısı A için 16k ve B için 13k'dir. toplam 69 satır (daha sonra bir sıralama uygulanır). Bu sorgu çok hızlı bir şekilde gerçekleşir.

TOP 1001Optimize edici eklediğimde bir karma eşlemesi kullanmıyor; bunun yerine ilk önce A tablosundaki sonuçları sıralar (aynı tahmini / gerçek 19k / 16k) ve B tablosuna karşı iç içe bir döngü yapar. B tablosunun tahmini satır sayısı şimdi 1'dir ve garip olan, TOP ndoğrudan B'ye karşı tahmini infaz sayısı (indeks arayışı) - her zaman 2n + 1 veya benim durumumda 2003 gibi görünüyor . Bu tahmin eğer değişirsem buna göre değişiyor TOP n. Tabii ki, bu yuvalanmış bir birleşim olduğundan, gerçek yürütme sayısı 16k'dır (tablo A'daki satırların sayısı) ve bu, sorguyu yavaşlatır.

Asıl senaryo biraz daha karmaşıktır, ancak bu temel fikri / davranışı yakalar. Her iki tablo da dizin aramaları kullanılarak aranır. Bu, SQL Server 2008 R2 Enterprise sürümüdür.

Bir sorgu TOP n içerdiğinde, veritabanı motoru TOP yan tümcesini görmezden gelen sorguyu çalıştıracağını ve daha sonra sonunda istenen satır sayısını belirten bu sonucu küçülteceğini tahmin ederdim. Grafiksel uygulama planı bunun böyle olduğunu gösteriyor gibi görünüyor - TOP "son" adımdır. Ama görünen o ki daha fazlası oluyor.

Yukarıdakilerin ifade edilme şekli, bir sorgunun nasıl yürüdüğüne dair yanlış bir zihinsel resminiz olabileceğini düşündürüyor. Bir sorgu planındaki bir işleç bir adım değildir (önceki adımın tam sonuç kümesinin sonraki adımla değerlendirildiği.

SQL Server , her operatörün Init () , GetRow () ve Close () gibi yöntemleri gösterdiği bir boru hattı yürütme modeli kullanır . Şöyle GetRow () adından da anlaşılacağı, bir operatör (şekilde üst operatör tarafından gerekli) isteğe bağlı olarak her seferinde bir satır üretir. Bu, Bloglar Çevrimiçi Gönderim Mantıksal ve Fiziksel İşleçler referansında belgelenmiştir ve blog gönderimde neden Sorgu Planlarının Geriye Doğru Çalıştırıldığını ayrıntılı olarak açıklamaktadır . Her seferinde bu satır modeli, sorgu yürütme için bir ses sezgisi oluşturulmasında esastır.

Sorum şu, TOPn cümlesi bir sorgunun yürütme planını nasıl (ve neden) etkiler?

TOPYarı birleştirmeler ve FAST n sorgu ipucu gibi bazı mantıksal işlemler , sorgu optimize edicinin uygulama planı alternatiflerini maliyetlendirme yöntemini etkiler. Temel fikir, olası bir plan şeklinin ilk n sırasını, tüm satırları döndürmek için optimize edilmiş farklı bir plandan daha hızlı bir şekilde döndürmesi olabilir .

Örneğin, endekslenmiş iç içe döngüler birleştirme işlemi, az sayıda satır döndürmenin en hızlı yoludur, ancak taramalarla karma veya birleştirme, daha büyük kümelerde daha etkili olabilir. Sorgu iyileştiricisinin bu seçimlerle ilgili nedenleri , işlemlerin mantıksal ağacında belirli bir noktaya bir Satır Hedefi koymaktır.

Bir satır hedefi, sorgu planı alternatiflerinin maliyetlendirilme biçimini değiştirir. Bunun özü, optimizer’in her bir operatöre, tam sonuç kümesi gerekliyse maliyetlendirmesiyle başlar, uygun noktada bir satır hedefi belirler ve daha sonra incelemesi gereken satır sayısını tahmin eden plan ağacından aşağı doğru çalışır. Satır hedefine ulaşmak için.

Örneğin, bir mantıksal TOP(10)mantıksal sorgu ağacında belirli bir noktada 10'luk bir satır hedefi belirler. Satır hedefine giden operatörlerin maliyetleri, satır hedefine ulaşmak için kaç satır üretmeleri gerektiğini tahmin etmek için değiştirilir. Bu hesaplama karmaşık bir hale gelebilir, bu nedenle tüm bunları tam çalışılmış bir örnek ve açıklamalı uygulama planları ile anlamak daha kolaydır . Satır hedefleri birleştirme türü seçiminden veya taramalar için arama ve aramaların tercih edilip edilmeyeceğinden daha fazla etkileyebilir. Bununla ilgili daha fazla ayrıntı burada .

Her zaman olduğu gibi, sıralı bir hedef temelinde seçilen bir uygulama planı, optimize edicinin muhakeme yeteneklerine ve kendisine sunulan bilgilerin kalitesine tabidir. Sıralı bir hedefi olan her plan pratikte gereken sayıda satırı daha hızlı üretemez, ancak maliyet modeline göre üretecektir.

Bir satır hedefi planının daha hızlı olmadığını kanıtladığı zaman, genellikle sorguyu değiştirmenin veya optimize ediciye doğal olarak seçilen planın en iyi olacağı şekilde daha iyi bilgi sağlamanın yolları vardır. Durumunuzda hangi seçeneğin uygun olduğu elbette ki ayrıntılarına bağlıdır. Satır hedefi özelliği genellikle çok etkilidir (buna rağmen paralel uygulama planlarında kullanıldığında dikkat edilmesi gereken bir hata vardır ).

Özel sorgunuz ve planınız burada ayrıntılı analiz için uygun olmayabilir (elbette dilerseniz gerçek bir uygulama planı sunun) ancak burada ana hatlarıyla açıklanan fikirler ilerlemenizi sağlayacak.

TOP'u kullandığınızda, Doktor daha az iş yapma fırsatı görür. 10 satır sorarsanız, tüm seti tüketmesi gerekmediği için iyi bir şans var. Böylece TOP operatörü sağa çok daha itilebilir. Bir sonraki operatörden (sağda), talep edene kadar satır talep etmeye devam edecektir.

TOP olmadan, sorgunun en sonunda verileri sıraladığını belirtiyorsunuz. Motor, birleşme tarafından kaç satırın önceden karşılanacağını bilirse, TOP'u solda konumlandırarak benzer bir plan kullanmayı seçebilir. Ancak bir Karma Eşleştirme yapma çabası nispeten yüksek ve muhtemelen bir Birleştirme Birleşmesi için seçenek olmadığından, Optimize Edici, TOP'u sağa daha fazla filtrelemeyi tercih edebilir.

B tablosu sorgulandığında, her seferinde tek bir satır alıyor. Bu yüzden tahmin 1'dir. Ayrıca zamanın sadece% 50'sini bulacağını varsayar. Bu yüzden onu bulmak için 2n + 1 ihtiyacı olacağını tahmin ediyor.