Авторитетне джерело, які <> і! = Однакові за продуктивністю у SQL Server

Розглянемо цю відповідь на ТАК, яка запевняє запитувача про <>оператора, що:

<>є ... те саме, що !=.

Але тоді коментер трубиться і каже:

Це правда, що вони, функціонально, однакові. Однак те, як оптимізатор SQL використовує їх, дуже відрізняється. = /! = просто оцінюються як істинні / хибні, тоді як <> означає, що двигун повинен шукати і бачити, чи є значення більше або менше, що означає більш високі показники продуктивності. Просто щось, що слід враховувати при написанні запитів, які можуть бути дорогими.

Я впевнений, що це помилково, але для того, щоб звернутися до потенційних скептиків, мені цікаво, чи може хтось надати авторитетне чи канонічне джерело, щоб довести, що ці оператори не просто функціонально однакові, але ідентичні у всіх аспектах?

Під час розбору SQL Server викликає, sqllang!DecodeCompOpщоб визначити тип оператора порівняння, який присутній:

Це відбувається задовго до того, що в оптимізаторі все входить.

Від операторів порівняння (Transact-SQL)

Відстежуючи код за допомогою налагоджувача та публічних символів *, sqllang!DecodeCompOpповертає значення в регістр eax** таким чином:

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

!=і <>обидва повертають 5, тому вони не відрізняються від усіх наступних операцій (включаючи компіляцію та оптимізацію).

Незважаючи на те, що зазначено вище, можна також (наприклад, використовуючи недокументований прапор трассировки 8605) подивитися на логічне дерево, передане оптимізатору, щоб підтвердити те, що обидва, !=і <>відобразити на ScaOp_Comp x_cmpNe(не рівне порівняння скалярного оператора).

Наприклад:

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);

обидва виробляють:

LogOp_Project QCOL: [P] .ProductID
    LogOp_Select
        LogOp_Get TBL: Production.Product (псевдонім TBL: P)
        ScaOp_Comp x_cmpNe
            ScaOp_Identifier QCOL: [P] .ProductID
            ScaOp_Const TI (int, ML = 4) XVAR (int, не належить, значення = 4)
    AncOp_PrjList 

Виноски

<sub>* Я використовую WinDbg ; доступні інші налагоджувачі. Загальнодоступні символи доступні через звичайний сервер символів Microsoft. Докладніші відомості див. У розділі « Поглиблення в SQL Server» за допомогою Minidumps консультативною командою клієнта SQL Server та налагодження SQL Server з WinDbg - вступ Клауса Ашенбреннера.

** Використання EAX для 32-бітних похідних Intel для повернення значень функції. Звичайно Win32 ABI робить це саме так, і я впевнений, що він успадковує цю практику ще в старі часи MS-DOS, де AX використовувався з тією ж метою - Майкл Кьорлінг</sub>

Я працюю в Microsoft у службі підтримки SQL, і я запитав Джека Лі, старшого інженера ескалації та експерта з питань тематики продуктивності SQL Server: "Чи трактується SQL! = Інакше, ніж <>?" і він сказав: "Вони однакові".

Я думаю, що наступне свідчить про те, що <>2 порівняння не роблять.

1. Стандарт SQL 92 визначає <>як не рівний оператор, ( http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt ). Технічно !=це розширення до стандарту (хоча я не можу думати про будь-які RDBMS, які не реалізують його).
2. Якщо SQLServer розглядався <>як 2 оператори, а не один, він би зробив те саме, для ><чого насправді є синтаксична помилка.

Це неправильно, "Книги онлайн" (BOL) говорять, що вони функціонально однакові:

! = (Не дорівнює) (Transact-SQL)

Якщо ви подивитесь на план виконання, де !=він використовується, у розділі Predicate він змінюється != на <>.