SQL触发器如何获取更新前后的差值_对比DELETED与INSERTED表-SQL-PHP中文网

sql server中after update触发器通过deleted表获取旧值、inserted表获取新值，必须用主键或唯一约束列inner join关联两表，禁止按顺序匹配或null直接比较。

sql触发器如何获取更新前后的差值_对比deleted与inserted表

在 AFTER UPDATE 触发器中，DELETED 表存更新前的整行，INSERTED 表存更新后的整行——这是 SQL Server 的底层语义：UPDATE 被实现为“先删旧行、再插新行”。两张表结构完全一致，且行数严格相等，一一对应。

你不能用 OLD.col 或 NEW.col（那是 MySQL/PostgreSQL 的写法），也不能靠 SELECT TOP 1 FROM DELETED 猜顺序——这些在 SQL Server 里要么语法报错，要么逻辑不可靠。

DELETED 和 INSERTED 是只读内存表，无法 CREATE / DROP，但可在触发器体内直接 SELECT 或 JOIN
如果原表有 50 列，这两张表每行都带全量数据；一次更新 10 万行，触发器里无谓的 SELECT * 可能直接拖垮性能
别在触发器里写 IF EXISTS(SELECT 1 FROM INSERTED) AND NOT EXISTS(SELECT 1 FROM DELETED) 来“判断是不是 INSERT”——AFTER UPDATE 中 DELETED 必然非空，这种判断纯属冗余

必须用主键（或唯一约束列）做 INNER JOIN，否则无法确定哪条旧记录对应哪条新记录。没有主键的表，DELETED 和 INSERTED 的行序不保证一致，按顺序匹配是典型错误。

单列主键：写 ON d.id = i.id，不要漏别名（d 和 i 是常用简写）
复合主键：比如 (order_id, line_no)，就得写全 ON d.order_id = i.order_id AND d.line_no = i.line_no
避免 LEFT JOIN 或 RIGHT JOIN——除非你在 INSTEAD OF 触发器中要区分 INSERT/UPDATE/DELETE 场景
绝对不要用 ORDER BY (SELECT NULL) 或 ROW_NUMBER() 强行对齐——两表无隐式顺序，这种技巧在并发或批量更新下必然出错

以下错误不是语法问题，而是语义误用，上线后难排查：

触发器逻辑正常跑通，但批量更新时日志里出现“旧金额=新金额”或字段错配——大概率是 JOIN 条件漏了复合主键中的某一列
触发器执行缓慢，SET STATISTICS IO ON 显示扫描了大量逻辑页——检查是否写了 SELECT * FROM DELETED d INNER JOIN INSERTED i ON ...，应只选需要的列，如 SELECT d.id, d.status, i.status
触发器里插入审计日志，但发现部分更新没记录——可能用了 IF d.status != i.status 却没处理 NULL 比较（NULL != 'A' 结果是 UNKNOWN），得改用 ISNULL(d.status, '') != ISNULL(i.status, '')
在视图上建了 INSTEAD OF UPDATE 触发器，却直接把 DELETED 当原表查——注意：此时 DELETED 和 INSERTED 仍可用，但是否真发生了变更，得由你代码判断，系统不保证

很多人以为 DELETED / INSERTED 是轻量级“变量”，其实它们是完整行副本的内存表。宽表 + 高频更新时，这里就是瓶颈源头。

如果原表含 text / ntext / image 列（已弃用但仍存在老系统），AFTER 触发器里不能直接查这些列，会报错；INSTEAD OF 触发器才允许访问
触发器影响多行时（比如 UPDATE orders SET status='shipped' WHERE created_date ），<code>@@ROWCOUNT 必须在触发器开头立刻捕获，后续任何 SELECT 都可能覆盖它
不要在触发器里调用耗时存储过程或远程查询——事务会卡住整个 UPDATE，下游应用可能超时
SQL Server 2019+ 支持 STRING_AGG 在触发器里拼差异字段，但要注意聚合前先过滤掉未变化的行，否则日志膨胀极快