MySQL Binlog本身不直接记录操作用户，但配置ROW格式、binlog_row_image=FULL及binlog_rows_query_log_events=ON后，可通过DELETE_ROWS_EVENT与邻近QUERY_EVENT交叉推断出执行人、时间、线程和具体行。
MySQL 本身不记录“谁在什么时间删了 id=123 的数据”，binlog 里也没有直接的用户名字段；但只要你配置得当，就能从 DELETE_ROWS_EVENT 和邻近事件中交叉推断出操作人、时间、线程和具体行——前提是 binlog 是 ROW 格式且关键开关已启用。
确认 binlog_format 是 ROW，否则审计无效
STATEMENT 模式下，binlog 只存原始 SQL（如 DELETE FROM users WHERE id = 123），看不到实际被删的行值，也拿不到执行上下文。ROW 模式才能记录每一行的旧值，是逆向追踪的基础。
- 执行
SHOW VARIABLES LIKE 'binlog_format'，必须返回ROW - 如果返回
STATEMENT或MIXED，当前 binlog 文件无法用于精准审计，需立即切为 ROW 并重启（但误删后不建议重启） - 同时检查
binlog_row_image = FULL：若为MINIMAL或NOBLOB，部分字段可能丢失，导致无法还原完整行
开启 binlog_rows_query_log_events=ON，否则看不到原始语句和用户
默认情况下，mysqlbinlog 解析出的 DELETE_ROWS_EVENT 前后只有 GTID 或 XID 事件，不含 SQL 内容或执行用户。这个变量一开，每个行事件前会插入一个 QUERY_EVENT，里面含：user@host、SQL 原文、时间戳（UTC）、线程 ID。
- 动态开启（需 SUPER 权限）：
SET GLOBAL binlog_rows_query_log_events = ON - 永久生效：在
my.cnf的[mysqld]下加一行binlog_rows_query_log_events=ON，然后FLUSH LOGS - 验证是否生效：用
mysqlbinlog --base64-output=DECODE-ROWS -v mysql-bin.0000xx | grep -A 5 "Query"，应能看到类似USER test_user@10.0.1.5的行
用 mysqlbinlog 定位 DELETE_ROWS_EVENT 并向上翻查 QUERY_EVENT
mysqlbinlog 默认不显示行数据，必须加 -v（verbose）和 --base64-output=DECODE-ROWS 才能解码出被删的行内容；再结合时间或位置范围缩小搜索范围，避免加载整个 GB 级 binlog。
- 先粗筛时间（注意时区）：
mysqlbinlog --base64-output=DECODE-ROWS -v --start-datetime='2026-04-11 14:30:00' --stop-datetime='2026-04-11 14:45:00' /var/lib/mysql/mysql-bin.000017—— 时间要换算成 UTC，否则可能漏掉 - 搜索
DELETE_ROWS_EVENT，找到后往上翻 3–5 行，找紧邻的QUERY_EVENT或GTID_LOG_EVENT，其中user@host和 SQL 就在那里 - 若没开
binlog_rows_query_log_events，就只能靠SHOW PROCESSLIST历史快照、应用日志、代理层（如 ProxySQL/MaxScale）日志来对齐时间窗口
audit 用户行为的硬限制：binlog 不存登录 IP、应用名、客户端证书信息
即使所有配置都正确，binlog 能给出的最多是 user@host（比如 app_rw@10.0.2.8），但不会告诉你这是哪个 Java 进程、用了哪个 JDBC URL、有没有带 application_name 参数。真正想做到细粒度审计，得靠：
- MySQL 8.0+ 的
audit_log插件（需单独安装启用，记录完整连接与语句） - 中间件层日志（如 ProxySQL 的
audit_log表、MaxScale 的log_info） - 网络层镜像（如 tcpdump 抓包 + pt-query-digest 分析）
- 应用侧埋点（统一 DAO 层打日志，记录 trace_id + user + sql + params）
别指望只靠 binlog 还原出“张三在管理后台点了删除按钮”——它只负责记“哪条数据变了”，不负责记“谁点的”。
