MySQL审计插件audit_log仅记录DML操作的语句模板、执行者和时间戳，不捕获行级变更细节；它能记录客户端直连发起的INSERT/UPDATE/DELETE事件（需audit_log_policy=ALL），但无法还原具体数据变化。
MySQL 审计插件（audit_log）本身不记录数据变更的详细内容，它只记录事件类型（如 QUERY）、执行者、时间戳和 SQL 语句模板，但不会捕获 UPDATE 或 DELETE 影响的具体行、旧值或新值——想靠它还原“谁把张三的工资从 8000 改成了 12000”，做不到。
audit_log 插件能抓到哪些“变更”操作？
它能记录客户端发起的 DML 语句（INSERT、UPDATE、DELETE）的执行事件，前提是：audit_log_policy 设为 ALL 或至少 COMMANDS；且语句是直接通过 MySQL 协议提交的（非存储过程内部、非复制线程、非 mysqldump 工具调用）。
-
QUERY类型事件会带sql_text字段，但仅限原始语句，例如"UPDATE users SET salary = ? WHERE id = ?"—— 参数值不会展开 - 失败的 DML（如权限不足、外键冲突）也会记录，但
status字段只返回错误码（如1142），不带错误信息文本 - 不记录任何行级变更细节：没有
old_value、new_value、affected_rows字段 -
binlog_format = ROW下的二进制日志才能提供这些，audit_log和它无关
为什么 audit_log_policy=ALL 还是漏掉大量变更？
因为 audit_log 的审计范围严格限定在“用户连接层”，而很多真实的数据变更根本不会经过这一层：
-
mysqldump --single-transaction导出时的SELECT不触发QUERY事件（走内部快照） - 存储过程中执行的
UPDATE只记录CALL proc_name，不记录内部 DML - 复制线程在从库上重放
UPDATE语句，不会生成审计日志（无用户上下文） -
PREPARE/EXECUTE动态 SQL 中的 DML，只有EXECUTE被记录，sql_text是占位符形式
真正能追踪数据变更的替代方案
要获得可追溯的、带上下文的数据变更记录，必须组合使用以下机制：
- 开启
binlog_format = ROW并保留足够时长的二进制日志；用mysqlbinlog --base64-output=DECODE-ROWS -v解析，可看到每行变更前后的完整镜像 - 对关键表加触发器，写入自定义审计表（
BEFORE UPDATE捕获OLD.*，AFTER UPDATE记录NEW.*） - 换用
server_audit插件（MariaDB 兼容版），配置server_audit_events = 'QUERY_DML'，它比audit_log更稳定捕获 DML 语句原文（但仍无行级详情） - 应用层埋点：在 ORM 或 DAO 层统一拦截并落库变更摘要（需改造代码，但可控性强）
别指望一个插件参数就解决数据变更溯源问题——audit_log 提供的是操作行为快照，不是数据状态流。真要还原“哪一行怎么变的”，得靠 ROW 格式 binlog 或触发器，二者缺一不可。
