SQL Server为何未执行分支内的错误INSERT仍会导致脚本失败

这是SQL Server刻意设计的*延迟名称解析（Deferred Name Resolution）*机制带来的副作用，不属于ANSI SQL标准规定的行为，是SQL Server特有的实现逻辑。

SQL Server执行一个T-SQL批处理时，会先做整批编译，再按逻辑分支执行，编译阶段不会判断IF等分支条件是否成立，只会按规则校验语句合法性：

• 如果语句引用的表、视图等对象在当前数据库元数据中不存在，编译器会暂时跳过对该语句的完整校验，默认假设对象会在后续执行流程中被创建，等真正执行到语句时再做二次编译校验，这就是延迟名称解析设计，初衷是支持“先写增删改语句、后写建表语句”的批处理编写方式。
• 如果语句引用的对象已经真实存在，编译器会在整批编译阶段直接完成全量校验：包括列数是否匹配、数据类型是否兼容、引用的列是否存在、权限是否足够等，只要校验不通过就直接抛错，不会进入执行阶段。

示例现象的对应解释 #

三条错误语句的报错差异完全符合上述规则：

• INSERT INTO NoSuchTable VALUES ('failure');：引用的NoSuchTable不存在，触发延迟名称解析，编译阶段跳过校验，不报错。
• SELECT * FROM NoSuchTable;：同样引用不存在的表，触发延迟解析，跳过校验，不报错。如果是针对已存在表写了错误列名的SELECT语句（比如查存在的表但写了不存在的列），哪怕放在永远不执行的分支里，也会在编译阶段直接报错。
• INSERT INTO TableWithManyColumnsTheFirstIsGuid VALUES ('failure');：引用的表已存在，编译器直接校验插入逻辑，发现提供的值数量和表定义的2列不匹配、类型也不兼容，直接在编译阶段抛出错误，根本不会走到判断IF条件的执行环节。

针对EF自动生成迁移脚本遇到的这类问题，不需要手动逐行改代码，可以用以下方式适配：

• 用动态SQL包装涉及已存在表、可能因为列变更导致语法错误的历史分支代码：动态SQL只有在实际被执行时才会编译，因为外层IF条件恒假，动态SQL永远不会触发编译，自然不会报错：

IF 1 = 2 -- 永远不执行的旧逻辑
BEGIN
  -- 引用不存在对象的语句可以直接放
  EXEC sp_executesql N'INSERT INTO TableWithManyColumnsTheFirstIsGuid VALUES (''failure'');'
END

• 调整迁移脚本生成逻辑，在生成最终执行脚本时自动清理已经废弃、永远不会触发的历史迁移代码段，从根源上避免无效代码进入编译环节。
• 用GO将不同逻辑段拆分为独立批处理，不过这种方式需要注意批处理之间的变量、临时表作用域问题。

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