审计日志必须与主业务共用同一事务以保证原子性，禁止独立提交；字段需包含操作上下文如app_name、client_ip、old_values/new_values等；时间戳应统一变量赋值避免时区与精度问题；性能优化应采用批量插入而非异步。
INSERT INTO 日志表前必须确保事务一致性
存储过程中写审计日志，最常踩的坑是日志写入失败导致主业务回滚，或日志写入成功但主业务失败——两者都会破坏审计可信度。根本解法不是“先写日志再执行”，而是让日志写入和主逻辑处于同一事务上下文，由存储过程自身事务控制统一提交或回滚。
这意味着：INSERT INTO audit_log 语句不能加 COMMIT，也不能放在独立事务块（如 SQL Server 的 SAVE TRANSACTION 或 MySQL 的 START TRANSACTION）里；否则会割裂原子性。
- PostgreSQL / SQL Server / Oracle：直接在主存储过程体中执行
INSERT INTO audit_log即可，天然继承当前事务 - MySQL：注意默认
autocommit=1，需在存储过程开头显式SET autocommit = 0，或确保调用方已开启事务 - 避免在触发器中重复写审计日志——容易和存储过程的日志冲突，造成冗余或时间戳错乱
日志表字段设计要覆盖操作上下文，不止是“谁干了什么”
只记录 user_id、action、created_time 远远不够。审计的核心价值在于“可追溯还原”，比如某条订单状态被误改，你得能定位到：是哪个应用连接、哪段代码、哪个前端用户、通过哪个接口、在什么数据状态下触发的修改。
建议日志表至少包含以下字段（以通用命名示例）：
-
audit_id（主键，自增或 UUID） -
operation_type（'UPDATE'/'DELETE'/'EXECUTE_PROC'） -
target_table（如'orders'）、target_pk（如order_id = 12345） -
old_values和new_values（JSON 或 TEXT 类型，存变更前后的关键字段快照） -
app_name、client_ip、session_id（需从应用程序传入，存储过程无法自动获取） -
executed_by（优先用应用层传入的@user_login，而非CURRENT_USER()，后者只是数据库账号）
INSERT INTO 审计日志时慎用 GETDATE() / NOW() —— 时区与精度陷阱
直接在 INSERT INTO audit_log 语句里写 NOW()（MySQL）或 GETDATE()（SQL Server），看似方便，实则埋下两个隐患：一是数据库服务器时区可能和应用服务不一致，二是高并发下多条日志可能拿到相同毫秒级时间戳，导致排序混乱。
更稳妥的做法是：在存储过程开头就统一获取一次时间戳，赋值给变量，后续所有日志行都复用它：
DECLARE @log_time DATETIME2(3) = SYSDATETIME(); -- SQL Server INSERT INTO audit_log (..., created_at) VALUES (@user, 'UPDATE', @log_time, ...);
同理，PostgreSQL 推荐用 CLOCK_TIMESTAMP()（非 NOW()），MySQL 建议用 NOW(3) 显式指定毫秒精度，并确认 @@time_zone 与应用一致。
性能敏感场景下，异步日志写入不可取，但可批量缓冲
有人试图用消息队列或临时表+后台任务做“异步审计”，这违背审计日志的强一致性要求——一旦主事务提交，日志必须已落盘。真有性能压力（比如单次操作要记 20+ 条审计行），可行方案只有两个：
- 把多条日志合并为单次
INSERT INTO ... VALUES (...), (...), (...)批量插入（注意各数据库行数上限，如 SQL Server 默认 1000 行） - 在存储过程内用表变量或临时表暂存日志数据，最后统一
INSERT INTO audit_log SELECT * FROM @log_buffer - 绝对不要在循环体内逐条
INSERT INTO，尤其当循环次数不可控时（如处理几千行订单）
真正难处理的是日志表本身成为瓶颈——这时候该考虑分区（按月/按业务域）、归档策略，而不是绕过事务一致性去“优化”。
