after delete触发器必须显式列出deleted字段或用for json auto序列化，避免select *、单变量赋值及原表回查；需结合sys.dm_exec_connections获取ip、original_login()获取用户，并确保权限与字段同步。
SQL Server 中 AFTER DELETE 触发器怎么写才不丢数据
直接 SELECT * FROM deleted 是高危操作，多行删除时字段错位、计算列为空、LOB 字段报错都可能发生。触发器必须适配真实表结构变化，不能靠“猜”。
- 显式列出字段：比如原表是
id, name, email, created_at，就写SELECT id, name, email, created_at FROM deleted，别省事 - 避免跨库引用：如果审计表在另一个数据库，
INSERT INTO otherdb.dbo.audit_table SELECT ... FROM deleted可能因权限或四部分命名失败，优先用同库 + 链接服务器或应用层中转 - 并发下别用单变量接收：
DECLARE @id INT; SELECT @id = id FROM deleted在删 10 行时只保留其中一行的值，SQL Server 不保证哪一行被赋值
deleted 表里怎么安全序列化整行数据
需要完整快照又不想每改一次表就手动同步触发器字段？用 FOR JSON AUTO 是目前最稳的方案，它不依赖列名顺序、自动跳过计算列、兼容稀疏列和 LOB。
- 写法是：
SELECT (SELECT * FROM deleted FOR JSON AUTO) AS DeletedData，返回一个NVARCHAR(MAX)字符串，可直接插入日志表的DeletedData字段 - 别用
CONVERT(NVARCHAR(MAX), ...)拼接：datetime 会变成无时区字符串，uniqueidentifier 缺少大括号，后续解析困难 - 注意 JSON 深度限制：默认支持嵌套 128 层，但实际业务表极少超限；若真有深层嵌套视图关联，应拆成主表 + 子表分别触发
触发器里如何记录操作来源（IP、用户、时间）
仅存数据不够，审计要求知道“谁、何时、从哪删的”。SQL Server 提供系统视图和函数，但调用时机和权限要卡准。
- 获取客户端 IP：
SELECT TOP 1 client_net_address FROM sys.dm_exec_connections WHERE session_id = @@SPID，必须加TOP 1，否则多行结果会导致赋值失败 - 获取登录名：
ORIGINAL_LOGIN()比SUSER_NAME()更可靠，后者可能被上下文切换影响 - 时间用
GETDATE()即可，不要用SYSDATETIMEOFFSET()除非你明确需要时区信息且日志表字段类型匹配 - 注意权限：
sys.dm_exec_connections需要VIEW SERVER STATE权限，部署前确认执行触发器的账号有该权限
为什么不能在 DELETE 触发器里再查原表验证
常见误区是写 IF EXISTS (SELECT 1 FROM Orders WHERE id IN (SELECT id FROM deleted)) 来“确认是否真删了”，这逻辑冗余且危险。
- 此时原表已提交删除，该查询永远返回空——不是没删，是刚删完，事务还没结束，但数据已不可见
- 在可重复读（REPEATABLE READ）隔离级别下，这个子查询可能引发锁等待甚至死锁，尤其高并发删同一主键范围时
- 真正需要校验的场景（如软删除拦截），应在
BEFORE DELETE阶段做，而不是在AFTER里回头查
触发器本身不保存上下文，所有字段映射、序列化方式、权限检查都得人工对齐——哪怕只加一列，忘了改触发器，日志就断。最易忽略的是 deleted 表在级联删除中只含直删行，子表变动不会出现其中。
