SQL Server IN ve EXISTS Performansı

Aşağıdakilerden hangisinin daha verimli olacağını merak ediyorum?

Kullanım konusunda her zaman biraz temkinli davrandım INçünkü SQL Server'ın sonuç kümesini büyük bir IFifadeye dönüştürdüğüne inanıyorum . Büyük bir sonuç kümesi için bu, düşük performansa neden olabilir. Küçük sonuç kümeleri için ikisinin de tercih edilebilir olduğundan emin değilim. Büyük sonuç kümeleri EXISTSiçin daha verimli olmaz mıydı ?

WHERE EXISTS (SELECT * FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

vs.

WHERE bx.BoxID IN (SELECT BoxID FROM Base WHERE [Rank = 2])

EXISTS daha hızlı olacaktır çünkü motor bir isabet bulduğunda, durum doğru olduğu için aramayı bırakacaktır.

İle IN, daha fazla işlemden önce alt sorgudaki tüm sonuçları toplayacaktır.

Kabul edilen cevap dar görüşlü ve soru biraz gevşek:

1) Solda, sağda veya her iki tarafta da bir örtme indeksinin mevcut olup olmadığını açıkça belirtmeyin.

2) Her ikisi de sol taraf setinin boyutunu ve sağ taraf setini giriş boyutunu hesaba katmaz.
(Soru sadece genel olarak büyük bir sonuç kümesinden bahsediyor ).

Optimize edicinin, (1) ve (2) nedeniyle önemli bir maliyet farkı olduğunda "içinde" ile "var" arasında dönüştürme yapacak kadar akıllı olduğuna inanıyorum, aksi takdirde yalnızca bir ipucu olarak kullanılabilir (ör. sağ tarafta aranabilir bir indeks).

Her iki form da dahili olarak birleştirme formlarına dönüştürülebilir, birleştirme sırası tersine çevrilebilir ve tahmini satır sayılarına (sol ve sağ) ve sol, sağ veya her iki taraftaki dizin varlığına bağlı olarak döngü, karma veya birleştirme olarak çalıştırılabilir.

SQL Server 2005 ve 2008 üzerinde bazı testler yaptım ve hem EXISTS hem de IN üzerinde, diğerlerinin de belirttiği gibi aynı gerçek yürütme planıyla geri döndüm. Optimizer optimumdur. :)

Dikkat edilmesi gereken bir şey var, EXISTS, IN ve JOIN bazen sorgunuzu tam olarak ifade etmezseniz farklı sonuçlar döndürebilir: http://weblogs.sqlteam.com/mladenp/archive/2007/05/18/60210 .aspx

Burada yüksek oy alan cevaplar da dahil olmak üzere birçok yanıltıcı cevap var (operasyonlarının zarar verdiğine inanmıyorum). Kısa cevap: Bunlar aynı.

(T-) SQL dilinde birçok anahtar sözcük vardır, ancak sonuçta, donanımda gerçekten gerçekleşen tek şey, yürütme sorgu planında görülen işlemlerdir.

Çağırdığımızda yaptığımız ilişkisel (matematik teorisi) işlem [NOT] INve [NOT] EXISTSyarı birleştirmedir (kullanırken birleşmeyi önleme NOT). Karşılık gelen sql-server işlemlerinin aynı ada sahip olması tesadüf değildir . Sadece (anti-) yarı birleşimlerden bahseden INveya EXISTSherhangi bir yerde işlem yoktur . Bu nedenle, mantıksal olarak eşdeğer INve EXISTSseçimin performansı etkilemesinin bir yolu yoktur, çünkü sonuçlarını almanın tek ve tek yolu (anti) yarı birleştirme yürütme işlemi vardır .

Bir örnek:

Sorgu 1 ( plan )

select * from dt where dt.customer in (select c.code from customer c where c.active=0)

Sorgu 2 ( plan )

select * from dt where exists (select 1 from customer c where c.code=dt.customer and c.active=0)

IN üzerinden EXISTS ile giderdim, aşağıdaki bağlantıya bakın:

SQL Server: JOIN - IN - EXISTS - mantıksal fark

Geri dönen sonuçlar açısından IN'in EXISTS veya JOIN'e eşit davrandığına dair yaygın bir yanlış kanı vardır. Bu kesinlikle doğru değil.

IN: Belirtilen bir değer, bir alt sorgu veya listedeki herhangi bir değerle eşleşirse doğru döndürür.

Var: Bir alt sorgu herhangi bir satır içeriyorsa doğru döndürür.

Birleştir: Birleştirme sütunundaki 2 sonuç kümesine katılır.

Blog kredisi: https://stackoverflow.com/users/31345/mladen-prajdic

Bu durumlarda yürütme planları tipik olarak aynı olacaktır, ancak indekslerin diğer tüm yönlerinde optimize edici faktörlerin nasıl olduğunu görene kadar, gerçekten asla bilemezsiniz.

Yani IN, EXISTS ile aynı değildir ve aynı uygulama planını üretecektir.

EXISTS genellikle ilişkili bir alt sorguda kullanılır, bu da EXISTS iç sorgusunu dış sorgunuzla birleştireceğiniz anlamına gelir. Bu, dış sorgu birleşimlerini çözmeniz gerektiğinden ve iç sorgu birleştiğinden sonuç üretmek için daha fazla adım ekleyecek ve ardından her ikisini de birleştirmek için where cümlelerini eşleştirecektir.

Genellikle IN, iç sorguyu dış sorgu ile ilişkilendirmeden kullanılır ve bu yalnızca bir adımda çözülebilir (en iyi durum senaryosunda).

Bunu düşün:

1. IN kullanırsanız ve iç sorgu sonucu milyonlarca farklı değer satırı ise, EXISTS sorgusunun yüksek performanslı olduğu (dış sorgu ile birleştirmek için doğru dizinlere sahip olduğu) göz önüne alındığında, muhtemelen EXISTS'den DAHA DAHA YÜKSEK performans gösterecektir.

2. EXISTS kullanırsanız ve dış sorgunuzla birleştirme karmaşıksa (gerçekleştirilmesi daha fazla zaman alır, uygun dizin yok) dış tablodaki satır sayısına göre sorguyu yavaşlatır, bazen tamamlanması için tahmini süre gün cinsinden olabilir. Verilen donanımınız için satır sayısı kabul edilebilir düzeydeyse veya verilerin önem düzeyi doğruysa (örneğin, büyük bir veri kümesinde daha az DISTINCT değeri) IN, EXISTS'den daha hızlı performans gösterebilir.

3. Yukarıdakilerin tümü, her bir tabloda makul miktarda satırınız olduğunda not edilecektir (adil olarak, CPU işlemlerinizi ve / veya önbelleğe alma için ram eşiklerinizi aşan bir şeyi kastediyorum).

Yani CEVAP BAĞIMLIDIR. IN veya EXISTS içinde karmaşık bir sorgu yazabilirsiniz, ancak genel bir kural olarak, çok sayıda farklı değere sahip çok sayıda satırınız olduğunda, sınırlı sayıda farklı değer ve EXISTS ile IN kullanmayı denemelisiniz.

İşin püf noktası, taranacak satır sayısını sınırlamaktır.

Saygılarımızla,

MarianoC

Optimize etmek için EXISTSçok basit olun; bir şeyin orada olması gerekir, ancak ilişkili alt sorgudan döndürülen herhangi bir veriye aslında ihtiyacınız yoktur. Sadece bir Boole koşulunu değerlendiriyorsunuz.

Yani:

WHERE EXISTS (SELECT TOP 1 1 FROM Base WHERE bx.BoxID = Base.BoxID AND [Rank] = 2)

İlişkili alt sorgu olduğu için RBAR, ilk sonuç isabeti koşulu doğru kılar ve daha fazla işlenmez.

Kafamın tepesinde ve doğru olduğu garanti edilmiyor: Bu durumda ikincinin daha hızlı olacağına inanıyorum.

1. İlkinde, ilişkili alt sorgu muhtemelen her satır için alt sorgunun çalıştırılmasına neden olacaktır.
2. İkinci örnekte, alt sorgu ilişkili olmadığı için yalnızca bir kez çalıştırılmalıdır.
3. İkinci örnekte, INbir eşleşme bulur bulmaz kısa devre yapacaktır.