真正可行的“无侵入式”数据变更审计必须在存储过程中显式埋点，即不修改业务逻辑、不依赖触发器或原生审计，而是在过程开头结尾插入轻量日志语句，确保上下文、参数、执行链路可追溯。
不能靠触发器或数据库原生审计实现“无侵入式”数据变更审计——它们要么捕获不到存储过程调用上下文，要么不记录参数、无法归属执行链路。真正可行的“无侵入”，是指**不修改业务逻辑主体、不依赖外部拦截机制、但又必须在存储过程中显式埋点**。
为什么触发器和SQL Server Audit都不算“无侵入”
触发器响应的是 INSERT/UPDATE/DELETE 语句，不是 EXEC 调用。你在 Orders 表上建了触发器，日志里只会写“UPDATE Orders”，但不会出现 usp_ProcessRefund 这个源头过程名；SQL Server 的 DATABASE AUDIT SPECIFICATION 能捕获 EXEC 动作，但 params_json 字段永远为空，也分不清是应用直连调用还是嵌套调用。
- 常见错误现象：审计表里
proc_name是NULL或UNKNOWN，查不到谁、什么时候、用什么参数改了哪几行 - 多个存储过程共用同一张业务表时，触发器日志混杂，无法反向归因
- 触发器内再写日志，可能因嵌套插入导致死锁，或被主事务回滚一并清除
显式埋点才是唯一可控路径
所谓“无侵入”，不是不写代码，而是**不改变原有逻辑分支、不包裹业务语句、只在关键位置追加轻量日志语句**。每个需审计的存储过程，在开头和结尾各插一条 INSERT INTO audit_log，字段用硬编码字符串（如 'usp_UpdateInventory'）而非 OBJECT_NAME(@@PROCID)，避免元数据查询开销和不可靠性。
-
audit_log表至少含：proc_name、executed_by（用ORIGINAL_LOGIN()，不用CURRENT_USER()）、executed_at（赋值给变量，如@log_time = SYSDATETIME()）、params_json（用CONCAT拼，如CONCAT('@sku=', @sku, ', @qty=', @qty)）、row_count（@@ROWCOUNT）、error_message（ERROR_MESSAGE()） - 不要把日志
INSERT放在主事务块里——主事务回滚会吞掉日志；改用EXEC sp_executesql+SET XACT_ABORT OFF，或写入带WITH (TABLOCK)的独立日志表 - 高频循环场景（如逐行处理订单）别每轮都插，先缓存到
#audit_temp，最后批量INSERT
跨数据库的事务隔离绕过方案
不同数据库对“事务内写日志”的限制不同，强行统一语法会失败。必须按引擎特性做适配：
- SQL Server：用
BEGIN TRY ... INSERT INTO audit_log ... END TRY BEGIN CATCH END CATCH包裹日志语句，确保失败不中断主流程 - MySQL：禁止在存储过程中直接
INSERT到被主逻辑操作的表，报错ERROR 1442；必须用INSERT IGNORE INTO audit_log（需唯一约束）或更稳妥的INSERT ... ON DUPLICATE KEY UPDATE ignored = VALUES(ignored) - PostgreSQL：默认函数运行在当前事务中，日志失败 = 主事务回滚；建
UNLOGGED audit_log表，并用VOLATILE函数包裹INSERT，加EXCEPTION WHEN OTHERS THEN NULL
最容易被忽略的一点：时间戳字段必须统一用变量赋值，比如 DECLARE @log_time DATETIME2 = SYSDATETIME()，而不是每条日志都调一次 SYSDATETIME()——高并发下毫秒级重复会导致去重困难、归档错乱。
