SQL Server Management Studio执行SQL报Msg 512错误咨询

两段SQL代码对比截图

问题背景 #

• 已编写多段SQL代码，第一段代码可正常执行，无任何报错
• 第二段代码预期返回与第一段完全一致的执行结果，但实际运行直接失败
• 需要定位第二段代码无法正常运行的根本原因

故障原因说明 #

这类「逻辑和可正常运行的代码看似一致、实际执行直接报错」的SQL问题，基本都是下面几个高频踩坑点，对着代码逐行核对即可：

• 别名引用顺序错误：SQL实际执行顺序为FROM > WHERE > GROUP BY > HAVING > SELECT > ORDER BY > LIMIT，列别名是在SELECT阶段才生成的，如果在第二段的WHERE/GROUP BY同级位置直接引用SELECT子句里刚定义的别名，除了非严格模式下的MySQL，绝大多数数据库引擎都会抛出「列不存在」的错误。第一段如果是嵌套了子查询、在外层引用别名，就不会触发该问题。
• 混入非法语法符号：第二段代码里大概率藏了肉眼不容易识别的全角空格、全角逗号、中文单引号/分号，或是SELECT字段列表末尾多打了半角逗号、字符串值的单引号没有闭合，这类问题靠逐行肉眼扫很容易遗漏，打开编辑器的符号高亮功能可以快速定位。
• 语法断句或表连接写法错误：如果第二段用了CTE（即WITH开头的公用表表达式），CTE和后续主查询之间不能加分号，多数数据库不支持单独执行CTE片段；如果用了逗号分隔多表名的隐式连接写法、没写全连接条件，要么触发笛卡尔积导致内存不足报错，要么会被数据库开启的安全更新模式直接拦截执行。
• 隐式类型转换失败：如果第二段写过滤条件时没有匹配字段类型，比如给字符串类型的字段直接传入数字值做等值匹配，碰到字段中存在非数字内容时就会抛出类型转换错误，第一段如果显式加了类型转换函数就不会触发该问题。

排查时不需要从头捋完整段代码，直接根据报错信息提示的行号，定位到报错位置往前排查3行，90%的问题都能快速找到。

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