TSQL IF条件为假时错误逻辑分支代码异常执行问题

这个现象是SQL Server的语句级编译机制和延迟名称解析规则共同导致的，本质是报错发生在批处理的编译阶段，根本没有进入到「IF条件判断→分支跳过」的执行流程，不存在分支内代码被偷偷执行的情况。

核心机制说明 #

SQL Server处理GO分隔的批处理代码时，会分两个阶段走：

• 编译阶段：逐条解析批内语句的语法、校验涉及的schema引用合法性，这个阶段完全不会求值IF这类控制流条件——控制流逻辑只有执行阶段才会生效。
• 执行阶段：按顺序执行编译通过的语句，遇到IF条件时计算布尔值，为假就跳过对应分支内的所有代码。

不同语句表现差异的原因 #

• PRINT、RAISERROR这类语句不依赖用户表的schema定义，编译阶段只要语法正确就会通过校验。等到执行阶段走到IF判断，发现条件为假就直接跳过整个分支，所以这两个语句永远不会被执行，也不会抛出异常。
• 涉及表读写的INSERT语句触发报错，是因为你引用的[tbl_Users]表本身是存在的：编译到这条INSERT语句时，SQL Server会直接读取系统元数据校验列的合法性，发现NonExistentColumn不存在就直接抛出无效列名的207错误。这个报错发生在编译期，比执行阶段的IF条件判断早得多，批处理直接终止，根本走不到分支判断的步骤。

你感知到的「间歇性触发」也很好解释：如果跑脚本的数据库版本里目标列还没被删除，编译校验列存在就会正常通过，执行阶段IF条件为假就跳过INSERT；如果跑在列已经被删除的版本上，编译阶段就会直接报错，看起来就像偶发异常。

补充：这也是延迟名称解析的典型边界：如果语句引用的是整张不存在的表，编译阶段会暂时放过校验，等执行到语句时再检查；但如果引用的表存在，表下的列、数据类型等属性必须合法，不管语句写在哪个控制流分支里，编译时都会强制校验。

幂等脚本的正确写法 #

要绕开编译期的schema校验，只需要把涉及可能被删除的列的操作，放到动态SQL中——动态SQL是独立的批处理，只有执行到对应代码时才会触发编译，完全受IF条件控制：

-- 先判断列是否存在
IF COL_LENGTH('dbo.tbl_Users', 'NonExistentColumn') IS NOT NULL
BEGIN
    -- 旧列相关操作全部放到动态SQL内，条件不满足时不会触发编译校验
    EXEC sp_executesql N'
        INSERT INTO [tbl_Users] ( NonExistentColumn ) VALUES (''Bar'');
        -- 其他涉及该旧列的UPDATE/DELETE语句也可以写在这里
    ';
END
GO

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