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

SQL Server 触发器里怎么拿到 UPDATE 前后的字段值

当你在 SQL Server 中编写 AFTER UPDATE 触发器，并需要精确对比特定字段在修改前后的变化时，数据库引擎已经提供了内置的解决方案。关键在于理解并使用两个系统临时表：Inserted 和 Deleted。它们并非物理表，无法手动创建或删除，但在触发器执行期间，你可以像查询普通数据表一样直接引用它们。

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

要掌握其原理，首先需要明确 SQL Server 对 UPDATE 操作的定义：它本质上被视为一个“删除旧行并插入新行”的组合过程。因此，Deleted 表完整保存了更新前的行数据（即旧值），而 Inserted 表则完整保存了更新后的行数据（即新值）。这两个表拥有完全相同的结构，并且行数严格对应，确保了数据比较的准确性。

如何关联 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 进行内连接是最安全、最常规的做法。在 AFTER UPDATE 触发器中，通常应避免使用 LEFT JOIN 或 RIGHT JOIN，除非在 INSTEAD OF 触发器这类特殊场景中有明确意图。
• 如果表的主键是复合主键（例如由 order_id 和 line_no 共同构成），则关联条件必须完整：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) 的逻辑，试图判断当前操作是否为插入。这在 AFTER UPDATE 触发器中是毫无意义的，因为对于任何更新操作，Deleted 表必然包含数据。

性能与可维护性容易被忽略的点

虽然访问 Inserted 和 Deleted 表看似轻量，但它们本质上是内存中的临时表，并且包含了被操作行的所有列数据。如果原表结构非常宽（例如包含数十个列），或者单次更新的数据量极大（例如上万行），那么触发器内进行的关联查询或向日志表插入数据的操作，很可能成为显著的性能瓶颈。

以下是一些实用的优化建议，可以帮助你规避潜在风险：

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

最后，还有一个最常被忽略但非常有效的优化步骤：在触发器开头加上一句 IF NOT EXISTS (SELECT 1 FROM Inserted) RETURN。这可以防止那些“空更新”（例如 UPDATE t SET x=x，值实际未发生变化）白白执行触发器内所有后续逻辑，从而节省不必要的系统资源消耗。