sql server 2022 中触发器仍可实现审计日志，但非首选方案——易拖慢业务、难防篡改、无法规避高权限用户绕过；全自动防抵赖审计应优先用 ledger 表或 server audit。
直接上结论：SQL Server 2022 中，触发器仍可实现审计日志，但**不是首选方案**——它容易拖慢业务、难以防篡改、且无法规避高权限用户绕过。真正全自动、防抵赖的审计，应优先用 LEDGER 表或 SERVER AUDIT，触发器只适合轻量、临时、或需自定义字段的补充场景。
触发器写审计日志时，INSERT/UPDATE/DELETE 的 old_data 和 new_data 怎么安全获取？
MySQL 或 PostgreSQL 的 OLD/NEW 是行级变量，SQL Server 没有等价语法，只能靠 inserted 和 deleted 两个伪表联查。但它们是集合，不是单行，直接 SELECT TOP 1 取值会出错（尤其批量操作）。
- 必须用
FOR JSON AUTO或FOR JSON PATH将整行转为 JSON 字符串，避免字段漏取或类型转换失败 - 对
UPDATE，要INNER JOIN inserted i ON i.id = d.id关联主键，不能假设顺序一致 -
DELETE只能从deleted取，INSERT只能从inserted取；UPDATE必须同时检查两者是否存在（IF EXISTS(SELECT 1 FROM inserted) AND EXISTS(SELECT 1 FROM deleted)） - 避免在触发器里调用
GETDATE()多次——事务内时间戳可能不一致，统一用SYSDATETIME()并存为变量
为什么触发器日志表里记录的 operated_by 经常是 sa 或 NT AUTHORITY\SYSTEM？
因为触发器以**执行者身份运行**，而非连接用户。如果应用用固定账号连库（如 sa），所有操作都会记成那个账号；Windows 集成认证下，也可能落到系统服务账户。
- 正确做法是让应用层显式传入操作人，例如在 SQL 中加参数：
UPDATE users SET name = @name WHERE id = @id; SELECT @operator = SYSTEM_USER;，再把@operator传进触发器逻辑 - 若无法改应用，可用
ORIGINAL_LOGIN()替代CURRENT_USER，它返回最初登录名，不受EXECUTE AS影响 -
CONNECTIONPROPERTY('client_net_address')可取客户端 IP，但 Web 场景下常是负载均衡地址，需配合应用层 X-Forwarded-For 使用
SQL Server 2022 触发器审计 vs. LEDGER 表：关键差异在哪？
触发器是“你写代码让它记”，LEDGER 是“SQL Server 自动记+自动验”，二者根本不在同一抽象层级。
- 触发器日志可被
DELETE FROM audit_log清空，DBA 权限即可绕过；LEDGER 表启用后，任何修改都会破坏哈希链，sys.ledger_get_blockchain_digest()一查就暴露 - 触发器写入失败会导致主事务回滚（默认行为），影响业务可用性；LEDGER 是数据库引擎内置机制，无额外事务开销
- 触发器要自己建表、写逻辑、处理并发、防递归；LEDGER 只需
WITH (LEDGER = ON)，历史视图和验证函数全自动生成 - LEDGER 不支持
TRUNCATE，不支持非主键更新（如无主键表无法启用），这是硬约束——而触发器没有这些限制，但也意味着没这些保护
真要上触发器审计，别只盯着怎么写，先问清楚：这日志是用来追责、合规报审，还是仅作内部调试？前者必须用 LEDGER 或 SERVER AUDIT；后者才值得花精力调触发器的 inserted/deleted 联查逻辑和 JSON 序列化容错。
