首页 > 数据库 >SQL触发器中如何获取更新前后的值_通过Inserted与Deleted表

SQL触发器中如何获取更新前后的值_通过Inserted与Deleted表

来源：互联网 2026-04-19 17:14:32

SQL Server 触发器如何获取UPDATE前后的字段值在编写 AFTER UPDATE 触发器时，若需要对比字段更新前后的变化，SQL Server 提供了标准的解决方案。系统内置了两个专用的临时表：Inserted 和 Deleted。它们并非物理表，无法手动创建或删除，但在触发器执行过程

SQL Server 触发器如何获取UPDATE前后的字段值

在编写 AFTER UPDATE 触发器时，若需要对比字段更新前后的变化，SQL Server 提供了标准的解决方案。系统内置了两个专用的临时表：Inserted 和 Deleted。它们并非物理表，无法手动创建或删除，但在触发器执行过程中，可以直接像查询普通表一样使用它们。

理解其原理至关重要：在 SQL Server 中，一次 UPDATE 操作被视作先 DELETE 旧行，再 INSERT 新行。因此，Deleted 表存储了更新前的完整行数据（旧值），而 Inserted 表则存储了更新后的完整行数据（新值）。这两个表结构完全相同，行数也必然相等，彼此一一对应。

长期稳定更新的攒劲资源： >>>点此立即查看<<<

SQL触发器中如何获取更新前后的值_通过Inserted与Deleted表

关联Inserted与Deleted表获取字段差异的方法

要正确关联新旧两行数据，必须使用主键（或具有唯一约束的列）进行关联。这是唯一可靠的方式。如果表未定义主键，Deleted 和 Inserted 表中的行顺序无法保证，按顺序匹配极易导致错误。

标准的关联查询写法如下：

SELECT
  d.id,
  d.name AS old_name,
  i.name AS new_name,
  d.amount AS old_amount,
  i.amount AS new_amount
FROM Deleted d
INNER JOIN Inserted i ON d.id = i.id;

需要注意以下几点：

使用 INNER JOIN 是最安全、最常规的做法。LEFT JOIN 或 RIGHT JOIN 可能引入 NULL 值，除非在 INSTEAD OF 触发器等特殊场景中有明确用途。
若表的主键是复合键（例如由 order_id 和 line_no 共同组成），则 ON 条件必须完整：ON d.order_id = i.order_id AND d.line_no = i.line_no。
切勿使用 SELECT TOP 1 或 ORDER BY (SELECT NULL) 等技巧试图“强行对齐”两表，这种方法完全无效且极不可靠。

不同触发器类型中Inserted与Deleted表的行为差异

这两个临时表的数据存在情况取决于触发器类型，规则非常明确：

在 AFTER INSERT 触发器中：仅 Inserted 表有数据（新插入的行），Deleted 表为空。
在 AFTER DELETE 触发器中：仅 Deleted 表有数据（被删除的行），Inserted 表为空。
在 AFTER UPDATE 触发器中：两个表均有数据，行数相等，分别对应更新前和更新后的行。
在 INSTEAD OF 触发器中：两表语义相同，但实际执行逻辑由编写代码控制，需自行判断数据是否真正发生了变更。

一个常见的误区是：在 UPDATE 触发器中编写类似 IF EXISTS (SELECT 1 FROM Inserted) AND NOT EXISTS (SELECT 1 FROM Deleted) 的逻辑，试图判断当前操作是否为 INSERT。这在 AFTER UPDATE 触发器中毫无意义，因为对于更新操作，Deleted 表必然包含数据。

性能与可维护性注意事项

虽然访问 Inserted 和 Deleted 表看似轻量，但它们实际上是内存中的临时表，包含了被操作行的所有列数据。如果原表非常宽（例如超过50列），或单次更新数据量巨大（例如上万行），触发器内的关联查询或向日志表插入数据的操作很可能成为性能瓶颈。

以下实用建议有助于规避风险：

仅查询所需列：务必避免使用 SELECT *。像 SELECT d.id, d.status, i.status 这样的写法，性能远优于 SELECT d.*, i.*。
避免行级复杂操作：尽量不要在触发器内针对 Inserted/Deleted 表的每一行调用标量函数或执行远程查询，否则性能将急剧下降。
评估逻辑复杂度：如果业务逻辑非常复杂（例如需要发送消息通知、调用外部API等），应优先考虑使用变更数据捕获（CDC）、变更追踪或在应用层进行异步处理，而非将所有逻辑塞入触发器。
全面测试：测试时务必覆盖单行更新和批量更新（例如 UPDATE TOP(1000) ...）两种场景。批量操作更容易暴露隐式类型转换或关联条件缺失索引等问题。