SQL Server'da yürütme planı oluşturma ne kadar belirleyicidir?


13

Aşağıdaki sabitler göz önüne alındığında:

  • Aynı yapıya sahip aynı veritabanı (tablolar, dizinler vb.)
  • Aynı veriler
  • Aynı SQL Server ve donanım yapılandırması
  • Aynı istatistikler
  • İstemcideki aynı SET seçenekleri
  • Aynı SQL Server sürümleri
  • Aynı iz bayrakları

Bu sabitler göz önüne alındığında, SQL Server her zaman belirli bir sorgu için aynı planı üretecek mi?

Değilse, başka düşünceler var mı? Belirsizliğin de göz önünde bulundurulması gereken bir unsuru var mı?


aynı planı söylemek yanlış olur, ama benzer planı söyleyebiliriz. DBA / Developer'ın kontrol edebileceği dış faktörlerle birlikte; "sorgu planı optimizasyon algoritmaları" ve "dahili sorgu maliyeti algoritmaları" SQL sunucu motorunun içine yazılır. "ne seçileceğini" her şekilde söyleme kontrolümüz yok. biz harici env ayarlayabilirsiniz motor en iyi seçmek için rehberlik. Optimize edici 0.001 maliyet farkı diyelim iki yürütme planı ile geldiyse belirli bir sorgu için o zaman hangi yürütme planı seçeceğini ilgisiz olacaktır sanırım.
Anup Şah

Bu konuda teorik olmanız gerektiğini düşünmüyorum. Farklı veritabanları ile 25 yıl çalıştım ve daha iyi yürütmek için bir sorguyu yeniden yazmak neredeyse her zaman mümkündür. Ve bazen sorguyu yazmanın bir yolu ile neden daha iyi olduğunu anlamak çok zor.

Yanıtlar:


13

Bu sabitler göz önüne alındığında, SQL Server her zaman belirli bir sorgu için aynı planı üretecek mi? Değilse, başka düşünceler var mı? Belirsizliğin de göz önünde bulundurulması gereken bir unsuru var mı?

Sorgu derlemesi bildiğim kadarıyla belirleyicidir. Orijinal QO tasarım hedeflerinden biri, veritabanının yalnızca istatistiki bir kopyasını kullanarak yürütme planlarının farklı bir sistemde yeniden oluşturulmasının mümkün olmasıydı . Kullanılabilir bellek miktarı ve mantıksal işlemci sayısı gibi yapılandırma parametreleri etrafında birkaç incelik vardır, ancak bunlar senkronize edilecek şeyler listeniz tarafından kapsanır.

Uyarı: Listenizdeki 'aynı' kelimesinin her açıdan aynı anlama gelmesi şartıyla bu doğrudur . Örneğin, 'aynı' istatistik iki sistem mevcut olabilecek, ancak bunlar sadece aynı histogram adımları ve yoğunluk bilgileri ise aynı .

Bununla birlikte, optimizasyon işlemi de son derece karmaşıktır , yani bu deterministik sürece tüm girdilerin aynı olmasını sağlamak ve tüm dahili durumların aynı kod yolunun belirli bir kod için optimize edici yoluyla alınmasını sağlayacak kadar benzer olmasını sağlamak zor olabilir. derleme. Sorgu veritabanının dışında (başka bir veritabanına veya örneğe) erişim içeriyorsa, bu ortamlar da aynı olmalıdır.

Listenize ekleyeceğim bir şey, herhangi bir plan kılavuzunun ikinci veritabanında da var olup olmadığını kontrol etmektir.


GETDATE()Sorgularda olduğu gibi deterministik olmayan fonksiyonların kullanılması da farklı bir plana sahip olacağınız anlamına gelebilir. Ana optimizer değeri doğrudan kullanmasa da, kardinalite tahmini kullanılabilir (bkz . Kardinalite Tahmini Sırasında Sabit Katlama ve İfade Değerlendirmesi ). Bu fark sınıfının sorunun kapsamına girip girmediğinden emin değilim, çünkü her iki sistem de aynı anda yürütülürse aynı planı üretecektir (veya daha genel olarak aynı giriş değişkenleri, parametreler ve fonksiyon değerleri ile).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.