SQL Server中通过AFTER DELETE触发器获取被删行完整数据，必须使用DELETED表并显式列出字段，配合FOR JSON PATH（加INCLUDE_NULL_VALUES和WITHOUT_ARRAY_WRAPPER）生成JSON快照，避免SELECT *、计算列及LOB字段处理错误，确保与原表结构同步且事务内原子写入审计表。
触发器里怎么拿到被删行的完整数据
SQL Server 的 DELETE 触发器中，只能通过 DELETED 临时表访问被删数据，它结构和原表一致，但不带主键约束、索引或默认值信息。想转成 JSON，不能直接 SELECT * FROM DELETED FOR JSON —— 因为 FOR JSON 在触发器里对临时表支持有限（尤其 SQL Server 2016–2017），且会丢掉 NULL 字段、日期格式混乱、没有类型提示。
实操建议：
- 显式列出所有列，避免用
*：防止新增列后触发器失效或 JSON 字段错位 - 对
datetime/datetime2列用CONVERT(VARCHAR, col, 126)格式化，避免 JSON 中出现/Date(...)/这类非标准写法 - 对可能为 NULL 的列，用
ISNULL(col, 'null')或保留原 NULL（FOR JSON默认省略 NULL 字段，加INCLUDE_NULL_VALUES才保留） - 若表有计算列或大对象（
XML、VARBINARY），需单独处理：计算列不会出现在DELETED中；VARBINARY要用CONVERT(NVARCHAR(MAX), col, 2)转十六进制字符串
SQL Server 2016+ 怎么安全生成结构化 JSON 快照
从 2016 开始，FOR JSON AUTO 和 FOR JSON PATH 可用于 DELETED，但必须配合子查询或 CTE，否则报错“无法对 INSERTED/DELETED 表使用 FOR JSON”。正确写法是把 DELETED 包进一个派生表或 CTE 再查。
示例（假设原表叫 Orders）：
SELECT (
SELECT
OrderID,
CustomerID,
CONVERT(VARCHAR(30), OrderDate, 126) AS OrderDate,
ISNULL(ShipAddress, '') AS ShipAddress,
TotalAmount
FROM DELETED
FOR JSON PATH, INCLUDE_NULL_VALUES, WITHOUT_ARRAY_WRAPPER
) AS json_snapshot注意点：
-
WITHOUT_ARRAY_WRAPPER很关键：删除单行时输出对象而非数组；批量删除时仍得用数组（去掉该选项），否则 JSON 无效 - 如果业务允许，优先用
FOR JSON PATH而非AUTO：PATH 显式控制字段别名和嵌套，AUTO 依赖列顺序和表名，容易因表结构变化出错 - JSON 字符串长度上限是
NVARCHAR(MAX)（约 2GB），但实际插入日志表前应加LEN()检查，超长需截断并打标记，否则触发器会失败
把 JSON 快照存到审计表要注意什么
不能直接在触发器里做复杂逻辑或远程调用，否则拖慢 DELETE 性能甚至阻塞事务。推荐写入本地带时间戳和操作类型的审计表，字段至少包括：AuditID（IDENTITY）、TableName（NVARCHAR(128)）、Operation（CHAR(1)，如 'D'）、DeletedAt（DATETIME2）、JsonData（NVARCHAR(MAX)）。
关键细节：
- 审计表必须和原表在同一个数据库、同一事务中写入，确保原子性；跨库写入需用
TRY...CATCH+ 补偿，但不推荐 - 避免在触发器里调用
GETDATE()多次：用变量缓存一次结果，否则同一批删除的多行可能时间戳微差，影响排序和去重 - 如果原表有高并发删除，审计表的
JsonData字段建议建全文索引或用SPARSE列压缩存储（仅当多数字段常为空时） - 不要在触发器里解析或校验 JSON 内容——那是下游服务的事，触发器只负责“快照即刻落地”
为什么不能用 INSTEAD OF DELETE 替代 AFTER DELETE
INSTEAD OF DELETE 看似更可控，但它会完全接管删除逻辑：你得手动写 DELETE FROM 原表 WHERE ...，同时还要保证外键、级联、权限检查等不被绕过。一旦漏掉原删除语句，数据就“删不动”了，而用户只看到成功返回，极其危险。
真实风险点：
- 触发器里执行
DELETE会再次激发自身，导致无限递归（即使设了RECURSIVE_TRIGGERS OFF，也难保其他触发器不联动） - 某些 ORM（如 Entity Framework）发来的
DELETE带参数化条件，INSTEAD OF里若没严格复现 WHERE 子句，可能误删整表 -
AFTER DELETE是唯一能确保“数据已删、快照可用”的时机；INSTEAD OF下DELETED表内容虽存在，但原表数据还在，快照和最终状态不同步
真正难的是字段动态映射和 NULL 处理的一致性，不是选哪种触发器类型。只要坚持显式列清单 + 统一时间格式 + 单事务写入，JSON 快照就能可靠捕获。
