SQL Server中VARCHAR列未加单引号查询为何联合条件时可正常执行？

这是个挺典型的隐式转换+查询优化器执行逻辑的场景，我来给你拆解背后的原因：

核心原因1：SQL Server的数据类型优先级规则 #

SQL Server对不同数据类型有明确的优先级排序，数值类型（比如INT）的优先级远高于VARCHAR。当你对不同数据类型的字段和值进行比较时，低优先级的类型会被自动转换为高优先级的类型：

• 当你单独执行SELECT * FROM table WHERE column2 IN (120012, 220015)时，SQL会尝试把整个column2列的VARCHAR值转换成INT类型。如果column2里存在任何非数值格式的字符串，就会触发你看到的Conversion failed when converting the varchar value...错误。

核心原因2：查询优化器的执行路径选择 #

当你加上column1 = 'QTR12345678'这个条件后，情况就变了：

• 查询优化器会评估每个条件的选择性（也就是能过滤掉多少数据）。如果column1的这个条件能快速把结果集缩小到极少的行数（比如只有几行满足），优化器会优先执行这个过滤步骤。
• 在得到这个极小的结果集后，再去检查column2的IN条件时，有两种可能：
  1. 剩下的行中column2的值刚好都是可以安全转换为INT的字符串，所以转换过程没有出错；
  2. 优化器判断转换IN列表里的数值为VARCHAR（和column2的原生类型匹配）的成本更低，于是直接把120012、220015转换成字符串来和column2比较，完全避免了转换column2列的操作。

不管是哪种情况，最终都没有遇到无法转换的值，所以查询顺利返回了正确结果。

重要提醒：这种行为不可靠！ #

虽然这次查询成功了，但这是一种“巧合”：

• 如果后续表中满足column1 = 'QTR12345678'的行里，column2出现了非数值的字符串，这个查询会突然报错；
• 隐式转换还可能导致column2上的索引失效，拖慢查询性能。

最佳实践：始终保证比较的两边类型一致，把IN列表里的数值加上单引号，写成：

SELECT * FROM table WHERE column1 = 'QTR12345678' AND column2 IN ('120012', '220015')

内容的提问来源于stack exchange，提问作者Corey