sql-server – lt;gt;和！=在SQL Server中性能相同的权威来源

在SO上思量 this answer可以向提问者担保关于<>策划者：

<> is … the same as !=.

但随后一位评述者说道：

It’s true that they are,functionally,the same. However,how the SQL optimizer uses them is very different. =/!= are simply evaluated as true/false whereas <> means the engine has to look and see if the value is greater than or less than,meaning more performance overhead. Just something to consider when writing queries that may be expensive.

我确信这是错误的,但为了办理隐藏的猜疑论者,我想知道是否有人可以提供势力巨子或类型来素来证明这些运算符不只在成果上沟通,并且在全部方面都沟通？

办理要领

这种环境产生在优化器中涉及的任何内容之前.

From 07001

07002

行使调试器和民众标记跟踪代码*,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(alias TBL: P)
        ScaOp_Comp x_cmpNe
            ScaOp_Identifier QCOL: [P].ProductID
            ScaOp_Const TI(int,ML=4) XVAR(int,Not Owned,Value=4)
    AncOp_PrjList 

脚注

*我用WinDbg;其他调试器可用.民众标记可通过常用的Microsoft标记处事器得到.有关具体信息,请参阅SQL Server客户咨询团队的Looking deeper into SQL Server using Minidumps和Klaus Aschenbrenner的SQL Server Debugging with WinDbg – an Introduction.

**在32位英特尔衍出产物上行使EAX来获取函数的返回值很常见.虽然,Win32 ABI就是这样做的,并且我很确定它在旧的MS-DOS期间担任了这种做法,个中AX用于统一目标 – Michael Kj?rling

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!