最可靠的数据审计方式是显式写日志：在存储过程中用临时表暂存、脱离主事务插入，记录proc_name、executed_by、params_json等关键字段，并为executed_at建索引。
在存储过程中实现数据审计与变更记录，最可靠的方式是显式写日志，而不是依赖触发器或数据库级审计功能。触发器无法捕获调用来源，SQL Server Audit 不带参数，MySQL 和 PostgreSQL 原生过程级审计能力极弱——你必须自己动手，在关键位置插入可控、可读、不拖慢主流程的日志。
为什么不能在存储过程里直接 INSERT INTO audit_log
直接写日志看似简单，但极易破坏事务一致性：主逻辑失败回滚时，日志也消失；日志表写入失败（如索引冲突、磁盘满），又可能让整个业务事务中断。更隐蔽的问题是并发写入冲突——多个会话同时执行同一存储过程，INSERT 可能因主键/唯一约束报错，而你没做错误处理，导致过程意外退出。
- 必须脱离主事务控制：SQL Server 中用
SET XACT_ABORT OFF+BEGIN TRY/END TRY包裹日志语句 - 避免用
CURRENT_USER()记录操作人——连接池下它返回数据库账号，不是真实用户；改用ORIGINAL_LOGIN()或应用层传入的@user_login - 时间戳统一赋值给变量：
DECLARE @log_time DATETIME2 = SYSDATETIME()，别每条日志都调用函数，防高并发下毫秒重复
audit_log 表该存哪些字段才真正有用
字段不是越多越好，而是要能还原“谁、什么时候、调了什么、传了什么、干成了没”。少一个关键字段，排查时就得翻代码、查监控、问开发，成本陡增。
-
proc_name：硬编码字符串（如'usp_UpdateCustomer'），比OBJECT_NAME(@@PROCID)更准，后者在动态SQL或嵌套调用中可能失真 -
executed_by：优先用应用传参的@user_login，次选ORIGINAL_LOGIN()，禁用CURRENT_USER() -
params_json：用CONCAT拼接（如CONCAT('@id=', @id, ', @status=', @status)），别查元数据，不依赖sp_help或sys.parameters -
start_time/end_time：分别在过程开头和结尾赋值@log_time，中间不用再查系统时间 -
row_count和error_message：结尾补上@@ROWCOUNT和ERROR_MESSAGE()（放在CATCH块里）
高频批量操作怎么避免日志写爆性能
一个存储过程循环处理 5000 条订单，如果每轮都 INSERT INTO audit_log，I/O 和锁争用会直接拖垮性能。这不是理论风险，是线上真实踩过的坑。
- 改用临时表暂存：
CREATE TABLE #audit_temp (step VARCHAR(50), target_id INT, ts DATETIME2) - 循环体内只
INSERT INTO #audit_temp，不碰物理表 - 循环结束后一次性
INSERT INTO audit_log SELECT * FROM #audit_temp - 若需逐行记录变更前后的数据，
old_data和new_data字段建议用FOR JSON AUTO（SQL Server）或JSON_OBJECT()（MySQL 5.7+）序列化，别拼大文本
MySQL 和 PostgreSQL 的特殊限制必须绕开
MySQL 在存储过程中直接 INSERT 到审计表，常报 ERROR 1442 (HY000): Can't update table 'audit_log' in stored function/trigger because it is already used by statement——这不是权限问题，是引擎强制限制。PostgreSQL 默认函数运行在事务内，日志失败 = 主事务回滚，违背审计“发出去就不管”的本质。
- MySQL：用
INSERT IGNORE INTO audit_log（需提前建好唯一索引），或更稳妥的INSERT ... ON DUPLICATE KEY UPDATE ignored = VALUES(ignored) - PostgreSQL：建
UNLOGGED audit_log表（不写 WAL，快），再定义VOLATILE函数，里面INSERT并EXCEPTION WHEN OTHERS THEN NULL - 所有数据库都必须检查参数：
log_bin_trust_function_creators（MySQL）、track_functions（PG），否则含写操作的过程可能创建失败
真正难的不是“怎么记”，而是“记下来之后能不能快速定位问题”——所以 audit_log 表的 executed_at 字段一定要有非聚集索引，不然查“昨天下午三点谁调了 usp_PayOrder”得全表扫描。别等出事了才补索引。
