在 SQL Server 2019 上运行 OR 运算符的意外顺序

Question

从 SQL Server 2008 R2 迁移到 SQL Server 2019 时遇到问题。 我的代码

DECLARE @str NVARCHAR(50) = 'all',
        @int TINYINT = 1

DECLARE @tmp TABLE (val nvarchar(MAX))
INSERT INTO @tmp VALUES('123')
INSERT INTO @tmp VALUES('all')

SELECT val
FROM @tmp
WHERE @str = 'ALL' OR @int = val

使用 SQL Server 2008 R2 时，没问题。预期的输出如下所示

val
123
all

但是，当我迁移到 SQL Server 2019 时，出现如下错误。此外，它只是在 2019 年不寻常地发生。

消息 245 级别 16 状态 1 第 8 行转换失败时转换 nvarchar 值 'all' 到数据类型 int。

如你所见，第二个条件OR @int = val意外发生了。

我想知道它是否由于与 OR operator 或 case sensitive ALL 与 all 的顺序相关的任何重大更改而失败下一个 SQL Server 2008 R2 版本。

---

更新

对不起，我的重现代码让你们感到困惑。 This is my original code

Answer 1

你应该做以下三件事中的两件事：

(

1. 要么使用DECLARE @int nvarchar(max) = 1

   或

2. 使用WHERE val = CONVERT(nvarchar(max), @int)

)

与

1. 改为使用STRING_SPLIT。即使在本机解决方案存在之前，该循环函数也是您用来拆分字符串的效率最低的方法之一。见https://sqlblog.org/split

这个db<>fiddle 小提琴演示。

而this one 说明了为什么WHERE @str = 'ALL' OR (@str <> 'ALL' AND @int = val) 不是解决方案。您选择的这些模式只有在@str 是始终 'all' 时才有效，因为当它是其他任何东西时它们都会中断。那么为什么有OR呢？

---

您一直坚持 SQL Server 应该服从从左到右的评估，但我们一直告诉您事实并非如此。

这里是an article by Bart Duncan at Microsoft，他在 SQL Server 上工作，在发布更多 cmets 或进一步编辑您的问题之前，您绝对应该完整阅读。不过，关键点是：

对于

WHERE <expr1> OR <expr2>

之类的事情，您不能依赖表达式评估顺序，因为优化器可能会选择在第一个谓词之前评估第二个谓词的计划。