为何执行INSERT时出现Msg 121错误？已确认列数匹配仍报错

哇，半天卡在这里确实够闹心的！虽然你确认了SELECT和INSERT的列数看起来一致，但前几次正常、最后一次报错的情况，大概率是动态SQL或分支逻辑里藏了容易忽略的坑——毕竟静态列数完全匹配的话，不会出现时好时坏的情况。

给你几个针对性的排查方向：

• 重点检查动态SQL拼接逻辑：如果存储过程里用到了EXEC或sp_executesql来拼接SQL字符串，会不会在最后一次迭代时，某个变量的内容意外改变了SELECT的列数？比如某个条件触发后，拼接的列名字符串多了一列，或者变量里混入了额外的逗号/列名。举个典型的坑：

  DECLARE @SelectCols NVARCHAR(MAX) = 'Col1, Col2'
  -- 最后一次迭代时，某参数导致@SelectCols被修改为'Col1, Col2, Col3'
  DECLARE @SQL NVARCHAR(MAX) = 'INSERT INTO TargetTable (Col1, Col2) SELECT ' + @SelectCols
  EXEC sp_executesql @SQL
  

  这种情况下，静态看列数是对的，但动态拼接后就会出现不匹配。

• 排查分支判断逻辑：存储过程里有没有IF/ELSE、CASE这类分支？会不会最后一次迭代的参数刚好触发了某个分支，而这个分支里的SELECT语句列数和INSERT目标表不一致？比如某个分支里多查了一列，平时没触发，最后一次刚好命中。

• 检查临时表/表变量的结构变化：如果过程里用到了临时表（比如#TempTable），会不会在循环过程中对临时表做了ALTER或者重新创建？或者表变量的定义被意外修改，导致最后一次INSERT时目标结构变了。

• 抓最后一次迭代的实际执行SQL：最直接的办法是在存储过程里加日志，把每次执行的INSERT对应的SELECT语句记录下来。比如新建一个简单的日志表：

  CREATE TABLE DebugSQLLog (ID INT IDENTITY, ExecuteTime DATETIME DEFAULT GETDATE(), SQLText NVARCHAR(MAX))
  

  然后在执行INSERT前，把要执行的SQL插入到日志表：

  -- 如果是动态SQL，直接记录@SQL变量
  INSERT INTO DebugSQLLog (SQLText) SELECT @SQL
  -- 如果是静态SQL，直接写死语句
  INSERT INTO DebugSQLLog (SQLText) SELECT 'INSERT INTO TargetTable (...) SELECT ...'
  

  报错后去查日志表的最后一条，就能看到实际执行的SQL到底有多少列，和INSERT的目标列数对比，问题一目了然。

• 留意隐式计算的额外列：有没有在SELECT里写了类似Col1 + Col2的表达式，但某一次迭代中其中一个列是NULL，或者不小心多写了一个表达式？不过这种情况概率较低，但也可以排查一下。

这种时好时坏的问题，往往不是静态代码的明显错误，而是特定参数下触发的隐藏逻辑问题，抓实际执行的SQL是最有效的排查手段。

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