<> Ve! = 'Nin yetkili olduğu kaynak SQL Server'daki performansta aynı

Düşünün bu cevabı hakkında asker güvence SO üzerinde <>olduğunu operatörü:

<>... aynı !=.

Ama sonra bir yorumcu bilgi toplar ve der ki:

İşlevsel olarak aynı oldukları doğru. Ancak, SQL optimizer'ın bunları nasıl kullandığı çok farklı. = /! = basitçe doğru / yanlış olarak değerlendirilir, bununla birlikte <> motorun bakmak ve değerin daha büyük mü yoksa küçük mü olduğunu görmek zorunda olduğu anlamına gelir; Pahalı olabilecek sorgular yazarken dikkat etmeniz gereken bir şey.

Bunun yanlış olduğuna eminim, ancak potansiyel şüphecileri ele almak için, bu operatörlerin sadece işlevsel olarak aynı olmadığını, her yönüyle aynı olduğunu kanıtlamak için herhangi birinin yetkili veya kanuni bir kaynak sağlayıp sağlamadığını merak ediyorum.

Ayrıştırma sırasında , SQL Server sqllang!DecodeCompOpmevcut karşılaştırma işlecinin türünü belirlemek için çağırır :

Bu, optimize edicideki herhangi bir şey dahil olmadan önce iyi bir şekilde gerçekleşir.

Gönderen Karşılaştırma Operatörleri (Transact-SQL)

Bir hata ayıklayıcı ve genel semboller * kullanarak kodun izlenmesi, sqllang!DecodeCompOpkayıt defterinde eax** aşağıdaki gibi bir değer döndürür :

╔════╦══════╗
║ Op ║ Code ║
╠════╬══════╣
║ <  ║    1 ║
║ =  ║    2 ║
║ <= ║    3 ║
║ !> ║    3 ║
║ >  ║    4 ║
║ <> ║    5 ║
║ != ║    5 ║
║ >= ║    6 ║
║ !< ║    6 ║
╚════╩══════╝

!=ve <>her ikisi de 5 döndürür, bu nedenle sonraki tüm işlemlerde (derleme ve optimizasyon dahil) ayırt edilemez .

Yukarıdaki noktaya ikincil rağmen, aynı zamanda mümkündür (örn belgesiz izleme bayrağı 8605 kullanarak) her iki onaylamak için optimize edici geçirilen mantıksal ağaca bakmak !=ve <>eşleme ScaOp_Comp x_cmpNe(eşit değil skaler operatörü karşılaştırma).

Örneğin:

SELECT P.ProductID FROM Production.Product AS P
WHERE P.ProductID != 4
OPTION (QUERYTRACEON 3604, QUERYTRACEON 8605);

SELECT P.ProductID FROM Production.Product AS P
WHERE P.ProductID <> 4
OPTION (QUERYTRACEON 3604, QUERYTRACEON 8605);

her ikisi de üretmek:

LogOp_Project QCOL: [P] .ProductID
    LogOp_Select
        LogOp_Get TBL: Üretim.Ürün (takma ad TBL: P)
        ScaOp_Comp x_cmpNe
            ScaOp_Identifier QCOL: [P]. Ürün Kimliği
            ScaOp_Const TI (int, ML = 4) XVAR (int, Sahip Değil, Değer = 4)
    AncOp_PrjList 

Dipnotlar

<sub>* WinDbg kullanıyorum ; diğer hata ayıklayıcıları mevcuttur. Genel semboller normal Microsoft sembol sunucusu üzerinden kullanılabilir. Daha fazla bilgi için bkz. Mini Sunucuları kullanarak SQL Server Müşteri Danışma Ekibi ve WinDbg ile Hata Ayıklama ile SQL Server'da daha derinlere bakma - Klaus Aschenbrenner tarafından yapılan bir giriş .

** Bir fonksiyondan dönüş değerleri için 32-bit Intel türevlerinde EAX kullanımı yaygındır. Tabii ki Win32 ABI bu şekilde yapıyor ve eminim ki AX'in aynı amaç için kullanıldığı eski MS-DOS günlerinde bu alıştırmayı miras alıyor - Michael Kjörling</sub>

Microsoft’ta SQL Desteği’nde çalışıyorum ve Kıdemli Eskalasyon Mühendisi ve SQL Server’ın Konu Uzman Uzmanı Jack Li’ye, “SQL işlem yapıyor mu! = <> 'Dan farklı mı? ve dediler ki, "Onlar aynı."

Aşağıdaki <>2 karşılaştırma yapmadığını kanıtlıyor düşünüyorum .

1. SQL Standard 92, <>operatöre eşit olmadığı anlamına gelir ( http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt ). Teknik olarak, !=standardın bir uzantısıdır (uygulayamayan herhangi bir RDBMS hakkında düşünemesem bile).
2. SQLServer <>bir tane değil, 2 operatör olarak değerlendirilirse, bunun için ><sözdizimi hatası olan aynısını yapardı .

Bu yanlıştır, Books Online (BOL) işlevsel olarak aynı olduklarını söyler:

! = (Eşit Değil) (Transact-SQL)

Eğer bir yürütme planı bakacak olursak !=Yüklem altında kullanıldığında, bu değişikliği != için <>.