我应该在 T-SQL 中使用 != 或 <> 表示不相等吗？

Posted 2023-03-24

【中文标题】我应该在 T-SQL 中使用 != 或 <> 表示不相等吗？

【英文标题】：Should I use != or <> for not equal in T-SQL?

【发布时间】：2009-04-06 20:56:15

【问题描述】：

我看到SQL 同时使用!= 和<> 表示不等于。首选语法是什么？为什么？

我喜欢!=，因为<> 让我想起了Visual Basic。

【问题讨论】：

另见：***.com/questions/7884/…

代码的可移植性。如果 ANSI SQL 很容易满足您的要求，那么最好使用它。您可以在所有数据库中使用相同的代码。例如。 SQL 书籍作者，想使用示例代码说明基本 SQL。

我想添加一个示例，其中只有 ANSI SQL 代码可能会出现问题 - 标准 SQL 支持选项 NULLS FIRST 和 NULLS LAST 来控制 NULL 的排序方式，但 T-SQL 不支持支持这个选项。

无需重新打开。标记的问题是重复的，只是增加了一个选项NOT (A = B)。

因为它让你想起了 Visual Basic 是一个不好的理由。这个问题当然可以没有这种意见。一个更好的理由就像 SQL 存储在 XML 中的答案之一中的原因一样。不知道为什么要将 SQL 存储在 XML 中，但这是一个更好的理由。

【参考方案1】：

大多数数据库都支持!=（流行的编程语言）和<> (ANSI)。

同时支持!= 和<> 的数据库：

mysql 5.1：!= and <> PostgreSQL 8.3：!= and <> SQLite：!= and <> Oracle 10g：!= and <> Microsoft SQL Server 2000/2005/2008/2012/2016：!= 和 <> IBM Informix 动态服务器 10：!= and <> InterBase/火鸟：!= and <> Apache Derby 10.6：!= and <> Sybase Adaptive Server Enterprise 11.0：!= and <> Mimer SQL 11.0：!= and <>

支持 ANSI 标准运算符的数据库，独家：

IBM DB2 UDB 9.5：<> Microsoft Access 2010：<>

【讨论】：

Django ORM 查询映射到 NOT (a = b) 而不是 (a <> b) 或 (a != b)。内部是一样的吗？

@buffer，它们在逻辑上是相同的，也就是说，它将匹配或排除同一组行。但是，特定的 RDBMS 品牌是否对其进行同样的优化取决于实现。也就是说，如果数据库品牌之间存在任何差异，我会感到惊讶。

旁注：你必须使用 C# 中的 LINQ ！=

!= 受 IBM DB2 LUW 10.5+ 支持

@TomStickel C# 中的 LINQ 不是 SQL。

【参考方案2】：

从技术上讲，如果您使用的是 SQL Server AKA T-SQL，它们的功能是相同的。如果您在存储过程中使用它，则没有性能理由使用其中一个。然后归结为个人喜好。我更喜欢使用 ，因为它符合 ANSI。

您可以在...上找到各种 ANSI 标准的链接

http://en.wikipedia.org/wiki/SQL

【讨论】：

我一直更喜欢使用 !=，因为它存在于我使用过的每一种受 C 语言影响的语言中，并且因为 Python documentation 说：“<> 和 != 的形式是“但是 SQL 不是 Python！

我喜欢使用 ，因为它让我想起了 XML。但是 SQL 不是 XML！

是的； Microsoft 自己建议使用 <> 而不是 != 专门用于 ANSI 合规性，例如在 Microsoft Press 70-461 考试培训套件“查询 Microsoft SQL Server”中，他们说“作为选择标准形式的示例，T-SQL 支持两个“不等于”运算符： 和 !=。前者是标准的，后者不是。这种情况应该是明智的：去标准的吧！”

我喜欢 因为它更容易打字。

我总是更喜欢 != 而不是 因为 != 与我所知道的每一种编程语言都是一致的，我认识第一次开始使用 SQL 的程序员，每当他们看到 时，他们会去那是什么？ ?

【参考方案3】：

'<>' 来自SQL-92 standard，而'!=' 是proprietary T-SQL 运算符。它也可以在其他数据库中使用，但由于它不是标准的，因此您必须根据具体情况使用它。

在大多数情况下，您会知道要连接到哪个数据库，因此这不是真正的问题。在最坏的情况下，您可能必须在 SQL 中进行搜索和替换。

【讨论】：

我看到mysql sql也使用它

我们能否继续将标准语言如此广泛的扩展称为专有扩展？在这一点上，似乎应该更新标准以要求或至少允许两种语法。

@JohanBoule 好吧，有一个 SQL 的书面标准，据我所知，!= 不是其中的一部分。尽管出于所有实际目的，它是一个事实上的标准，但我们不应该混淆什么是标准功能，什么不是标准功能。

它说不是超过 25 年的 SQL-92 标准，所以我高度怀疑 SQL-92 甚至在今天使用......@JohanBoulé

【参考方案4】：

ANSI SQL 标准将<> 定义为“不等于”运算符，

http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt (5.2 <token> and <separator>)

根据 ANSI/SQL 92 标准，没有 != 运算符。

【讨论】：

你知道 92 标准已经超过 25 年了吧.....如果你使用 25 年的标准编写 SQL，老实说我有点担心你的代码...... ..

@Yunfei Chen 重点不是人们可能会在一个仅支持ANSI/SQL 92标准中的东西的系统中编写。关键是 ANSI/SQL 92 标准中包含的内容比标准中未包含的内容在数据库系统中具有更广泛的一致性覆盖。这就是选择“”的充分理由。如果有人创建了一个新的 DBMS，您现有的数据库代码可能会被移植到某一天，并且它只支持两个运算符之一 - 它更有可能是“”而不是“！=”。

如果您在 DBMS 之间移植数据库代码，将 != 更改为 将是您遇到的最少的问题...

【参考方案5】：

<> 是符合 SQL-92 标准的有效 SQL。

http://msdn.microsoft.com/en-us/library/aa276846(SQL.80).aspx

【讨论】：

两者都有效，但 '' 是 SQL-92 标准。

【参考方案6】：

对于SQL Server，它们都有效且相同，

https://docs.microsoft.com/en-us/sql/t-sql/language-elements/not-equal-to-transact-sql-exclamation

【讨论】：

这是特定于 SQL Server 的。诚然，他询问了 SQL Server，但你能找到 ANSI 规范参考，看看它是否保证对于我们这些喜欢了解这类事情的人来说是可移植的？

@Joel Coehoorn，如果您非常移植您的 T-SQL 代码“”和“！=”将是您最不必担心的！

移植不是问题 - 作为开发人员，您需要在环境之间来回切换。一致性很好。

【参考方案7】：

微软自己似乎更喜欢<> 而不是!=，这从他们的表约束中可以看出。我个人更喜欢使用!=，因为我清楚地把它读作“不等于”，但是如果您输入[field1 != field2]并将其保存为约束，下次查询时，它将显示为[field1 <> field2]。这告诉我正确的做法是<>。

【参考方案8】：

!= 尽管不是 ANSI，但更符合 SQL 作为一种可读语言的真正精神。它尖叫不相等。 <> 说对我来说（小于，大于）这很奇怪。我知道其意图是小于或大于因此不等于，但这是一种非常复杂的方式来表达非常简单的事情。

出于一大堆愚蠢的原因，我不得不进行一些长 SQL 查询并将它们亲切地放入 XML 文件中。

可以说 XML 完全没有被 <> 打倒，我不得不将它们更改为 != 并在我被操纵之前检查自己。

【讨论】：

为什么不只是CDATA呢？当您的查询包含 XML 时会发生什么？

当有人需要一个小于比较的查询时会发生什么？或任何其他 XML 保留符号？这是我听过的最奇怪的理由，因为我喜欢其中一个而不是另一个。那你在写C代码的时候，有没有偏爱可以用XML表达而不转义的运算符呢？

【参考方案9】：

您可以在 T-SQL 中使用任何您喜欢的。 The documentation 表示它们的功能相同。我更喜欢!=，因为它在我（基于C/C++/C#）的头脑中读作“不等于”，但数据库专家似乎更喜欢<>。

【参考方案10】：

我了解 C 语法 != 由于其 Unix 传统而存在于 SQL Server 中（早在 Sybase SQL Server 时代，Microsoft SQL Server 6.5 之前）。

【参考方案11】：

另一种方法是使用除<> 或!= 以外的NULLIF 运算符，如果两个参数相等NULLIF in Microsoft Docs，则返回NULL。所以我相信可以为<>和!=修改WHERE子句如下：

NULLIF(arg1, arg2) IS NOT NULL

我发现，在某些情况下，使用 <> 和 != 不适用于日期。因此使用上面的表达式就可以了。

【讨论】：

我不确定这个函数在所有极端情况下的索引使用方面是否会像 <> 一样好。另外，可读性肯定差很多……

正如我在答案中提到的，这在 2014 年的日期字段中对我有用。不确定限制其他答案的条款/条件是什么，但看看一些赞成票，这似乎也在帮助别人。

您可能在比较具有时间成分的日期。使用 CAST(date1) AS DATE CAST(date2) AS DATE 是更好的方式去恕我直言

【参考方案12】：

我更喜欢使用!= 而不是<>，因为有时我使用<s></s> 语法来编写SQL 命令。在这种情况下，使用!= 可以更方便地避免语法错误。

【讨论】：

这很好地解释了您对使用其中一个的偏好。

【参考方案13】：

它们都在 T-SQL 中被接受。但是，使用 <> 似乎比 != 快很多。我刚刚运行了一个使用!= 的复杂查询，平均运行时间约为 16 秒。我将它们更改为<>，现在查询平均需要大约 4 秒才能运行。这是一个巨大的进步！

【讨论】：

如果您在 SQL Server 中一个接一个地运行两个类似的查询，它可能会在内存中缓存数据并针对类似的查询进行优化。如果你按相反的顺序做，你可能会发现相反的结果！

这也是错误的，他们不会有两个功能完全相同的运算符，而一个“只是因为”速度较慢。同一个查询产生不同执行时间的原因有很多。

只看执行计划，看看有没有不同

【参考方案14】：

虽然它们的功能相同，但!= 表示完全“不等于”，而<> 表示大于和小于存储的值。

考虑>= 或<=，这在将您的索引纳入查询时会很有意义...<> 在某些情况下会运行得更快（使用正确的索引），但在其他一些情况下（索引免费）它们将运行相同。

这还取决于您的数据库系统如何读取值!= 和<>。数据库提供者可能只是简化它并使它们功能相同，因此这两种方式都没有任何好处。 PostgreSQL 和 SQL Server 没有捷径；如上所示。

【讨论】：

您的陈述有任何支持参考吗？ PostgreSQL、Oracle 和 MySQL 中的两个运算符似乎完全相同。

这是完全错误的，当您在脑海中组合这些字符时，它可能看起来像“大于和小于存储的值”，但对于词法分析器来说，这只是表示令牌。

相关资源不足！

我很同情。很多时候，我根据在其他语言和环境中的个人经验，根据看似合乎逻辑的假设做出假设。我学会了不要那样做；我几乎总是会查看操作员的源文档以确认代码的真正含义