mysql审计日志仅记录语句级操作（如delete语句）和执行者user@host，无法还原被删行原始值、事务id、变量展开条件或权限继承链；需确认插件active、policy=all、日志路径可写且文件存在。
MySQL 审计日志插件本身不直接记录“谁删了哪条数据”，它只记录语句级操作（如 DELETE FROM users WHERE id = 123）和执行者上下文（user@host），但**无法还原被删的具体行值，也不能回溯权限继承链或角色生效状态**。真要定位生产库误删，必须确认插件已启用、策略设为 ALL、日志路径可写，且你有权限读取该文件。
audit_log 插件是否真正加载并生效
很多线上环境看似开了审计，实际插件根本没加载成功——重启 MySQL 后没检查状态，等于白配。
-
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'audit_log';返回的PLUGIN_STATUS必须是ACTIVE；若为空或DISABLED，说明插件未加载 - 检查配置文件
my.cnf是否漏掉关键项：plugin-load-add=audit_log.so和audit_log_policy=ALL缺一不可；只写audit_log=ON不起作用 - 运行
SELECT @@audit_log_policy;，返回值必须是ALL或LOGINS,QUERIES；若为NONE或空字符串，策略未生效 - 插件加载失败时通常无报错，日志静默缺失——别假设“配了就对”，一定要查
INFORMATION_SCHEMA.PLUGINS
审计日志里能查到什么、不能查到什么
审计日志是 JSON 格式文本文件，不是数据库表，不能用 SQL 查询，也**不记录被删数据的原始值、事务 ID、绑定变量展开后的条件，更不包含角色链或权限来源**。
- 能查到：时间戳、
user（如"admin@10.0.1.5"）、query（原样 SQL，含WHERE条件）、db（当前默认库） - 不能查到：
id=123这条记录删前的完整字段值；也不能知道这个admin当时是否通过SET ROLE切换了高权限角色 - 日志默认写入 MySQL 数据目录（由
SHOW VARIABLES LIKE 'audit_log_file';确认），不是/var/log/mysql/；若 MySQL 用户无写权限，日志会完全不生成，且无提示 - 如果误删发生在凌晨，而日志按天轮转，得确认
audit_log_rotate_on_size或定时脚本没把当天日志提前压缩归档
为什么 grep "DELETE" 可能找不到真实误删操作
因为 DELETE 语句可能被 ORM 拼接、被存储过程封装、或被代理层重写，导致审计日志中根本不出现在顶层 query 字段里。
- ORM 如 MyBatis 的
<foreach></foreach>批量删除，审计日志里是一条带占位符的语句（如DELETE FROM orders WHERE id IN ( ? )），?不会展开，无法定位具体 ID - 存储过程中执行
DELETE，审计日志只记CALL proc_name()，不记内部语句；除非开启audit_log_include_accounts并配合log_bin_trust_function_creators=OFF，否则连调用者都难锁定 - 某些中间件（如 ProxySQL、ShardingSphere）会改写 SQL，审计日志看到的是中间件发来的语句，
user@host是中间件 IP，不是真实客户端 - 若应用使用连接池且长连接复用，
user@host是连接池账号（如app_pool@127.0.0.1），需结合应用层日志里的 trace_id 或 X-Request-ID 关联真实用户
audit_log 和 binlog 必须配合使用才可靠
单靠 audit_log 只能知道“谁在什么时候发了 DELETE”，但不知道“删了哪些行”；单靠 binlog（ROW 格式）能知道“删了哪些行”，但默认不记用户——二者缺一不可。
- 确保
binlog_format = ROW且binlog_rows_query_log_events = ON，这样mysqlbinlog -v解析时，每个DELETE_ROWS_EVENT上方才会附带含# User@Host的QUERY_EVENT - audit_log 中的
timestamp和 binlog 中的event time时区可能不一致（前者本地，后者 UTC），交叉比对前必须统一换算 - 如果 audit_log 文件里有一条
DELETE FROM users WHERE status = 'pending'，而 binlog 显示删了 2000 行，说明这是批量误操作，不是单条删除——这时更要查应用代码里有没有漏掉LIMIT或条件写错 - 最危险的情况：audit_log 记录了操作，但对应时间段的 binlog 已被
PURGE BINARY LOGS清理，或expire_logs_days设得太小；此时 audit_log 成了唯一线索，但无法还原数据
真正棘手的不是日志查不到，而是日志里查到的 user@host 是个服务账号，背后调用链跨越了网关、API 层、任务调度器三层，而每一层都没打操作人标识——这种情况下，审计日志只是起点，不是终点。
