SQL Server中UPDATE前保留原数据需用OUTPUT子句或触发器：OUTPUT DELETED.*可将更新前快照写入持久备份表，确保与主更新原子性一致；触发器须用AFTER UPDATE配合deleted表，且备份表结构须严格同步主表。
UPDATE 之前怎么保留原数据？
直接在UPDATE 语句里加备份逻辑是行不通的——SQL Server 不允许在单条 UPDATE 中同时写入目标表和备份表。必须拆成两步：先存快照，再更新。核心思路不是“自动备份”，而是“显式捕获变更前状态”。
常见错误现象：UPDATE 执行后发现改错了，但没留任何历史记录；或者用临时表 #old 存数据，结果事务回滚时临时表被清空，备份也丢了。
- 最稳妥的做法：用
OUTPUT子句把更新前的整行写进持久表（比如Backup_Users_BeforeUpdate），而不是临时表或变量 - 必须在同一个事务中完成：
INSERT INTO BackupTable OUTPUT ... INTO ... UPDATE ...，否则并发修改可能导致备份与实际更新不一致 - 注意字段顺序：如果目标表有计算列、标识列或默认约束，
OUTPUT DELETED.*会包含它们，但插入备份表时需确保列匹配（建议显式列出字段，而非用*）
示例（同步备份用户年龄变更）：
BEGIN TRANSACTION; INSERT INTO Users_Backup_History (UserID, UserName, UserAge, UpdatedAt, Reason) SELECT DELETED.UserID, DELETED.UserName, DELETED.UserAge, GETDATE(), 'Age correction' FROM Users WHERE UserID = 123 OUTPUT DELETED.*; -- 这行只是返回结果，不写入 <p>UPDATE Users SET UserAge = 35 WHERE UserID = 123;</p><p>COMMIT;
为什么不能只靠事务日志或数据库备份？
事务日志（LOG）和完整备份（BACKUP DATABASE）确实能还原，但它们不是“按行级更新前快照”——你无法快速定位某次 UPDATE 修改了哪几行、原始值是多少。
使用场景差异：
- 需要审计某次具体修改（比如法务查谁改了合同金额）→ 必须用
OUTPUT DELETED或触发器写入专用备份表 - 整库误操作后恢复 → 用
RESTORE DATABASE+ 日志备份链，但耗时且影响服务 - 只想防手抖改错 →
SET IMPLICIT_TRANSACTIONS ON配合ROLLBACK更轻量，但不留下可查记录
性能影响：每次 UPDATE 都写备份表，IO 和存储增长明显。建议只对关键业务表（如 Orders、Accounts）启用，且定期归档旧备份数据。
触发器方案要注意什么？
用INSTEAD OF UPDATE 或 AFTER UPDATE 触发器自动备份，看似省事，但容易踩坑。
常见错误现象：触发器里写备份表时发生死锁；或备份表结构没随主表变更而同步，导致插入失败。
-
AFTER UPDATE触发器里用SELECT * FROM deleted是安全的，但必须确保备份表字段与deleted兼容（比如主表加了NOT NULL新列，备份表没加就会报错） - 避免在触发器里调用远程链接服务器或复杂函数，延迟会拖慢所有
UPDATE - 测试时务必验证：当
UPDATE影响 0 行时，触发器是否仍执行？多数情况下应跳过，否则产生无意义备份记录
真正复杂的点在于一致性边界——备份动作和主表更新必须原子性地落在同一事务内，而触发器天然满足这点；但手工写的 INSERT+UPDATE 块若漏掉 TRANSACTION 或异常未 ROLLBACK，备份就成孤岛数据了。
