使用临时表追踪UPDATE未影响行时的异常问题排查

看起来你遇到的问题大概率是**@@ROWCOUNT被意外覆盖**了，咱们一步步来拆解和解决：

为什么你的IF @@ROWCOUNT <1没生效？ #

最常见的原因有两个：

1. 触发器干扰：如果TABLE1上存在触发器，触发器执行的最后一条SQL语句会直接覆盖@@ROWCOUNT的值。哪怕触发器里只是一条空操作或者查询语句，都会把原本UPDATE的影响行数给冲掉。
2. 隐性操作影响：如果在UPDATE和IF判断之间有其他隐性执行的语句（比如某些SQL Server扩展功能、自定义的会话设置），也可能篡改@@ROWCOUNT。

另外你代码里还有个小笔误：最后DROP TABLE #temp，但你创建的临时表是#not_updated，这会导致清理失败，但不是导致查询无结果的直接原因。

修复你的现有代码 #

最稳妥的方式是把@@ROWCOUNT的值立刻保存到变量里，避免被后续操作覆盖。修改后的单条更新逻辑如下：

DECLARE @row_count INT; -- 声明变量存储更新行数

CREATE TABLE #not_updated ( NOT_UPDATED VARCHAR(30) );

UPDATE TABLE1 SET COL1 = 'text1A' WHERE COL2 LIKE 'text1B';
SET @row_count = @@ROWCOUNT; -- 立刻保存当前UPDATE的影响行数
IF @row_count = 0 INSERT INTO #not_updated SELECT 'text1B';

UPDATE TABLE1 SET COL1 = 'text2A' WHERE COL2 LIKE 'text2B';
SET @row_count = @@ROWCOUNT;
IF @row_count = 0 INSERT INTO #not_updated SELECT 'text2B';

-- ... 剩下的600+条更新逻辑同理 ...

SELECT * FROM #not_updated;
DROP TABLE #not_updated; -- 修正笔误，清理正确的临时表

这样不管有没有触发器或者其他干扰，变量@row_count都会准确记录当前UPDATE的影响行数，判断逻辑就不会出错了。

更简便的批量处理方式 #

写600+条重复的UPDATE和IF实在低效，推荐用批量映射+左连接匹配的方式，一步搞定所有更新和未匹配记录统计：

-- 1. 创建临时表，存放所有更新规则（把你的600+条规则批量插入进来）
CREATE TABLE #update_mappings (
    New_Col1_Value VARCHAR(100),
    Col2_Match_Pattern VARCHAR(30)
);

INSERT INTO #update_mappings (New_Col1_Value, Col2_Match_Pattern)
VALUES
    ('text1A', 'text1B'),
    ('text2A', 'text2B'),
    -- ... 这里放剩下的600+条规则 ...
    ('textN', 'textN');

-- 2. 一次性完成所有更新操作
UPDATE t1
SET t1.COL1 = um.New_Col1_Value
FROM TABLE1 t1
INNER JOIN #update_mappings um
    ON t1.COL2 LIKE um.Col2_Match_Pattern;

-- 3. 找出没有匹配到任何行的规则（即未更新的条目）
SELECT um.Col2_Match_Pattern AS NOT_UPDATED
INTO #not_updated
FROM #update_mappings um
LEFT JOIN TABLE1 t1
    ON t1.COL2 LIKE um.Col2_Match_Pattern
WHERE t1.COL2 IS NULL;

-- 4. 查看未更新的结果
SELECT * FROM #not_updated;

-- 5. 清理临时表
DROP TABLE #update_mappings;
DROP TABLE #not_updated;

这种方式不仅代码量骤减，批量更新的执行效率也远高于600+条单独的UPDATE，后期维护也更方便——只要更新#update_mappings里的数据即可，不用修改大量重复代码。

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