RECOMPILE sorgu ipucu kullanılırken sorgular arasındaki yürütme süresinde anıtsal fark

Aynı SQL Server 2005 örneğinde çalışan hemen hemen aynı iki sorgu var:

1. Birincisi SELECTLINQ tarafından oluşturulan orijinal sorgudur (Biliyorum, biliyorum ... Ben uygulama geliştiricisi değilim, sadece DBA :).
2. İkincisi, birincisi ile tamamen aynıdır OPTION (RECOMPILE), sonunda bir a eklenmiştir .

Başka hiçbir şey değiştirilmedi.

Birincisi her çalıştırıldığında 55 saniye sürer.
İkincisi 2 saniye sürer.

Her iki sonuç kümesi de aynıdır.

Bu ipucu neden performansta bu kadar dramatik bir kazanç sağlar?

Üzerindeki Çevrimiçi Kitaplar girişi RECOMPILEçok ayrıntılı bir açıklama sunmuyor:

SQL Server Veritabanı Altyapısı'na, sorgu için oluşturulan planı yürüttükten sonra atmasını söyler ve sorgu optimize ediciyi bir sonraki sorgu çalıştırıldığında bir sorgu planını yeniden derlemeye zorlar. RECOMPILE belirtmeden, Veritabanı Altyapısı sorgu planlarını önbelleğe alır ve yeniden kullanır. Sorgu planları derlenirken, RECOMPILE sorgu ipucu sorgudaki yerel değişkenlerin geçerli değerlerini kullanır ve sorgu saklı yordamın içindeyse, geçerli değerler herhangi bir parametreye iletilir.

RECOMPILE, depolanmış yordamın tamamı yerine yalnızca saklı yordam içindeki sorguların bir alt kümesinin yeniden derlenmesi gerektiğinde WITH RECOMPILE yantümcesini kullanan bir saklı yordam oluşturmak için kullanışlı bir alternatiftir. Daha fazla bilgi için, bkz. Saklı Yordamları Yeniden Derleme. RECOMPILE, plan kılavuzları oluştururken de kullanışlıdır. Daha fazla bilgi için bkz. Plan Kılavuzlarını Kullanarak Dağıtık Uygulamalarda Sorguları En İyileştirme.

Sorgum çok sayıda yerel değişken olduğundan, tahminim SQL Server'ı OPTION (RECOMPILE)sorgu ipucunu kullandığımda (ciddi olarak) optimize edebildiğidir .

Baktığım her yerde insanlar OPTION (RECOMPILE)bundan kaçınılması gerektiğini söylüyor . Bunun açıklaması genellikle bu ipucunu kullanmanın SQL Server'ın bu exection planını yeniden kullanamaması ve bu nedenle her seferinde yeniden derlemek için zaman kaybetmesi gerektiğidir.
(Ama) Devasa performans avantajı göz önüne alındığında, bu sorgu ipucunu bu sefer kullanmanın iyi bir şey olacağını düşünmeye meyilliyim.

Kullanmalı mıyım? Değilse, SQL Server'ı bu ipucu olmadan ve uygulamayı değiştirmeden daha iyi bir yürütme planı kullanmaya zorlamanın bir yolu var mı?

Microsoft SQL Server 2005'te Sorgu İyileştiricisi tarafından Kullanılan İstatistikler makalesinde belgelendiği gibi

Sorgu yükleminde parametre veya değişmez değer yerine yerel bir değişken kullanırsanız, iyileştirici düşük kaliteli bir tahmin veya yüklemin seçiciliği için bir tahmin kullanır. Yerel değişkenler yerine sorguda parametreleri veya değişmezleri kullanma

Geliştirici bir sütun için hiç bir kullanılabilir istatistikleri olması, o olacaktır tahmin ki, bir =öncül satır,% 10 eşleşir BETWEEN% 9 ve herhangi >, >=, < and <=% 30 aynı olacaktır. Sütun istatistikleri mevcutsa, bir =yüklem aşağıdaki gibi farklı şekilde ele alınacaktır.

Bir sorguda yerel değişkenler kullanıldığında bile, eşitlik tahminlerinde tahminden daha iyi bir tahmin kullanılır. " @local_variable = column_name" Formunun koşulları için seçicilik, sütun_adı için histogramdaki ortalama değer frekansı kullanılarak tahmin edilir. Bu nedenle, örneğin, sütun_adı sütunu tüm benzersiz değerleri içeriyorsa 1/(number of unique values in column), doğru olan bir seçicilik tahmini kullanılır.

Yani bu aslında için kullanmakla aynı OPTIMIZE FOR (UNKNOWN). Düz bir 10%tahminden daha doğru olabilir , ancak sorguladığınız belirli değerlere uygun değildir.

SQL Server'ı her çalıştırıldığında bir sorguyu optimize etmeye zorlamak ve sorgunun en iyi duruma getirilmesi sırasında kardinalliği ve maliyeti tahmin etmek için yerel değişkenlerin değerlerini kullanmak üzere RECOMPILEsorgu ipucunu sorguya ekleyin .

Kullanımı ile RECOMPILEsize muhtemelen daha doğru önem düzeyi tahminleri ve bu nedenle siparişleri katılmak ile farklı bir planı alıyorsanız / daha gerçek sorgunun farklı bölgelerinden dönen satır sayısı uygun türde katılmak.