CTE, Alt Sorgu, Geçici Tablo veya Tablo Değişkeni arasında bir performans farkı var mı?

Bu mükemmel SO sorusundaCTE ve arasındaki farklar sub-queriestartışıldı.

Özellikle sormak istiyorum:

Hangi durumlarda aşağıdakilerin her biri daha verimli / daha hızlıdır?

• CTE
• Alt Sorgu
• Geçici Tablo
• Tablo Değişkeni

Geleneksel olarak, çok sayıda iç içe geçmiş alt sorgudan daha okunabilir göründüklerinden temp tables, geliştirmede çok kullandım stored procedures.

Non-recursive CTEs veri kümelerini çok iyi bir şekilde içine alır ve çok okunabilirdir, ancak her zaman daha iyi performans göstereceklerini söyleyebilecek belirli durumlar var mı? ya da en verimli çözümü bulmak için her zaman farklı seçeneklerle uğraşmak zorunda mıyız?

DÜZENLE

Son zamanlarda, verimlilik açısından, geçici tabloların ilişkili bir histogram yani istatistiklere sahip oldukları için iyi bir ilk seçenek olduğu söylendi.

SQL, bildirimsel bir dildir, yordamsal bir dil değildir. Yani, istediğiniz sonuçları tanımlamak için bir SQL deyimi oluşturursunuz. SQL motoruna işin nasıl yapılacağını söylemiyorsunuz .

Genel bir kural olarak, SQL motorunun ve SQL optimizer'ın en iyi sorgu planını bulmasına izin vermek iyi bir fikirdir. Bir SQL motoru geliştirmek için yıllarca süren çabalar vardır, bu yüzden mühendislerin nasıl yapabileceklerini bildiklerini yapmasına izin verin.

Tabii ki, sorgu planının optimal olmadığı durumlar vardır. Daha sonra, daha iyi performans elde etmek için sorgu ipuçlarını kullanmak, sorguyu yeniden yapılandırmak, istatistikleri güncellemek, geçici tablolar kullanmak, dizinler eklemek vb.

Sorunuza gelince. CTE'lerin ve alt sorguların performansı teorik olarak aynı olmalıdır çünkü her ikisi de sorgu optimize ediciye aynı bilgileri sağlar. Bir fark, bir kereden fazla kullanılan bir CTE'nin bir kez kolayca tanımlanıp hesaplanabilmesidir. Daha sonra sonuçlar depolanabilir ve birden çok kez okunabilir. Ne yazık ki, SQL Server bu temel optimizasyon yönteminden yararlanmak gibi görünmüyor (bu ortak alt sorgu ortadan kaldırması diyebilirsiniz).

Geçici tablolar farklı bir konudur, çünkü sorgunun nasıl çalıştırılacağı konusunda daha fazla rehberlik sağlarsınız. Önemli bir fark, optimize edicinin sorgu planını oluşturmak için geçici tablodaki istatistikleri kullanabilmesidir. Bu performans artışlarına neden olabilir. Ayrıca, bir kereden fazla kullanılan karmaşık bir CTE'niz (alt sorgu) varsa, bunu geçici bir tabloda saklamak genellikle performans artışı sağlar. Sorgu yalnızca bir kez yürütülür.

Sorunuzun yanıtı, özellikle düzenli olarak yürütülen karmaşık sorgular için beklediğiniz performansı elde etmek için oynamanız gerektiğidir. İdeal bir dünyada, sorgu optimize edici mükemmel yürütme yolunu bulur. Sık sık yapsa da, daha iyi performans elde etmenin bir yolunu bulabilirsiniz.

Kural yok. Ben CTEs daha okunabilir bulmak ve bunları kullanmak sürece onlar gerçek sorunu araştırmak yerine tahminim CTE sorun olduğunu ve farklı bir yaklaşım kullanarak yeniden yazmış deneyin bu durumda bazı performans sorununu, sergilerler. Sorunda genellikle niyetimi sorgu ile bildirmek için seçtiğim yoldan daha fazlası var.

CTE'leri çözebileceğiniz veya alt sorguları kaldırabileceğiniz ve bunları #temp tablosu ile değiştirebileceğiniz ve süreyi azaltabileceğiniz durumlar kesinlikle vardır. Bunun nedeni, eski istatistikler, hatta doğru istatistikler elde edememe (örneğin, tablo değerli bir işleve katılma), paralellik veya hatta sorgunun karmaşıklığı nedeniyle en uygun planın üretilememesi ( bu durumda onu parçalamak optimize ediciye bir savaş şansı verebilir). Ancak, #temp tablosu oluşturmakla ilgili G / Ç'nin, CTE'yi daha az çekici kullanarak belirli bir plan şeklini oluşturabilecek diğer performans yönlerinden ağır basabileceği durumlar da vardır.

Dürüst olmak gerekirse, sorunuza "doğru" bir cevap vermek için çok fazla değişken var. Bir sorgunun ne zaman bir yaklaşım veya başka bir lehine ne zaman bahşedileceğini bilmenin öngörülebilir bir yolu yoktur - teorik olarak, bir CTE veya tek bir alt sorgu için aynı semantiğin aynısını yürütmesi gerektiğini bilin . Bunun doğru olmadığı bazı durumlar sunduğunuzda sorunuzun daha değerli olacağını düşünüyorum - optimize edicide bir sınırlama keşfetmiş olabilirsiniz (veya bilinen bir tane keşfetmiş olabilirsiniz) veya sorgularınız anlamsal olarak eşdeğer olmayabilir veya bu optimizasyonu engelleyen bir öğe içeriyorsa.

Bu nedenle, sorguyu sizin için en doğal görünen bir şekilde yazmanızı ve yalnızca optimize edicinin yaşadığı gerçek bir performans sorununu keşfettiğinizde sapmanızı öneririm. Şahsen ben onları CTE, sonra alt sorgu, rütbe #temp tablo son çare olmak.

#temp materalize edilmiş ve CTE değil.

CTE sadece sözdizimidir, bu yüzden teoride sadece bir alt sorgudur. Yürütülür. #temp gerçekleştirildi. Bu nedenle, birçok kez yürütülen bir birleşimde pahalı bir CTE #temp'de daha iyi olabilir. Öte yandan, kolay bir değerlendirme yapılmazsa, ancak birkaç kez #temp yüküne değmez.

SO üzerinde tablo değişkeni sevmiyorum bazı insanlar ama onları gibi #temp daha somutlaştırılmış ve daha hızlı oluşturmak gibi. Sorgu iyileştiricinin #temp ile tablo değişkenine göre daha iyi yaptığı zamanlar vardır.

#Temp veya table değişkeninde PK oluşturma yeteneği, sorgu optimizer'a CTE'den daha fazla bilgi verir (CTE'de PK bildiremezsiniz).

Sadece 2 şey her zaman bir CTE yerine # Temp Tablo kullanmak her zaman tercih edilir yapmak düşünüyorum:

1. CTE'ye birincil anahtar koyamazsınız, böylece CTE tarafından erişilen veriler, geçici tablodaki PK veya Dizin'e erişmek yerine CTE tablolarındaki dizinlerin her birini çaprazlamak zorunda kalacaktır.

2. Bir CTE'ye kısıtlamalar, dizinler ve birincil anahtarlar ekleyemediğiniz için, sürünen hatalara ve kötü verilere daha eğilimlidirler.

-bugün dün

İşte #table kısıtlamalarının CTE'lerde olmayan kötü verileri önleyebileceği bir örnek

DECLARE @BadData TABLE ( 
                       ThisID int
                     , ThatID int );
INSERT INTO @BadData
       ( ThisID
       , ThatID
       ) 
VALUES
       ( 1, 1 ),
       ( 1, 2 ),
       ( 2, 2 ),
       ( 1, 1 );

IF OBJECT_ID('tempdb..#This') IS NOT NULL
    DROP TABLE #This;
CREATE TABLE #This ( 
             ThisID int NOT NULL
           , ThatID int NOT NULL
                        UNIQUE(ThisID, ThatID) );
INSERT INTO #This
SELECT * FROM @BadData;
WITH This_CTE
     AS (SELECT *
           FROM @BadData)
     SELECT *
       FROM This_CTE;