需用mysqlbinlog解析ROW格式binlog，查找DELETE_ROWS_EVENT及邻近GTID/QUERY事件中的用户、时间、线程信息，结合时间窗口与应用日志交叉定位误删操作。
怎么从 binlog 找到谁删了哪条记录
MySQL 本身不记录“谁在什么时间删了 id=123 的数据”，但 binlog 记录了所有写操作的原始语句或行变更。关键在于：你得用 mysqlbinlog 解析出具体 DELETE 事件，并结合 ROW 格式 + 时间戳 + 用户信息（如果开启了 log_bin_trust_function_creators 或有代理日志）交叉定位。
实操建议：
- 确认 binlog 格式是
ROW（SHOW VARIABLES LIKE 'binlog_format'），STATEMENT模式下看不到被删的具体行值，基本没法逆向追踪 - 用
mysqlbinlog --base64-output=DECODE-ROWS -v解析 binlog 文件，-v是关键，否则只显示 event header，看不到 actual rows - 搜索
DELETE_ROWS_EVENT，再往上翻看紧邻的GTID_LOG_EVENT或QUERY_EVENT，里面可能含执行用户、时间、线程 ID；若没开binlog_rows_query_log_events=ON，就只能靠时间窗口+应用日志对齐 - 注意时区：
mysqlbinlog默认按系统本地时区输出时间，而 binlog 里存的是 UTC，用--base64-output=DECODE-ROWS -v --start-datetime='2024-05-20 14:00:00'时得换算成 UTC
误删后立刻停写，但 binlog 已 rotate 怎么办
binlog rotate 后旧文件可能被 purged（尤其开了 expire_logs_days），但只要文件还在磁盘上，就能读。真正危险的是：误删后继续写入，新操作会覆盖你正在找的上下文（比如事务边界、前后状态），让还原更模糊。
实操建议：
- 立刻执行
FLUSH LOGS，把当前 binlog 切走，避免新写入污染待分析文件 - 查
SHOW BINARY LOGS确认哪些文件还存在，别只盯mysql-bin.000001—— 误删可能发生在mysql-bin.000017 - 用
mysqlbinlog --stop-datetime或--stop-position截断解析，防止加载整几个 GB 的 binlog 拖慢分析；先粗筛时间范围，再精读 - 如果 binlog 被自动清理了，且没开
binlog_checksum=CRC32，别指望从残留碎片里拼出完整事件 —— CRC 校验缺失时，损坏的 event 可能静默跳过，导致漏掉关键 DELETE
用 mysqlbinlog 还原删除前的数据，为什么 INSERT 语句插不回去
因为 mysqlbinlog 输出的 INSERT INTO ... VALUES 是基于删除前的快照生成的，但它不保证主键/唯一键不冲突、不检查外键约束、不处理自增偏移，直接执行大概率报错。
实操建议：
- 别直接
mysqlbinlog xxx | mysql—— 这会重放全部事件，包括你不想恢复的后续更新 - 用
--skip-gtids和--exclude-gtids排除无关事务；或用sed/awk提取特定 table + event 的 INSERT 片段，手动改写成INSERT IGNORE或REPLACE INTO - 如果表有
AUTO_INCREMENT，还原前先SELECT MAX(id)，再ALTER TABLE ... AUTO_INCREMENT = N，否则新插入可能触发重复键错误 -
mysqlbinlog在ROW模式下输出的 INSERT 是“反向构造”的，字段顺序严格对应表定义，但如果你中途改过表结构（比如删过列），它仍按老结构输出，字段数对不上就会报Column count doesn't match value count
audit plugin 和 binlog 审计哪个更靠谱
binlog 是 MySQL 自带、开箱即用的底层变更记录，audit plugin（如 MariaDB 的 server_audit 或 Percona 的 audit_log）是额外模块，侧重连接、语句、用户维度审计。两者不是替代关系，而是互补：binlog 告诉你“删了什么”，audit log 告诉你“谁、什么时候、从哪台机器、用什么客户端发的 DELETE”。
实操建议：
- audit plugin 默认不记录行级数据（比如 WHERE 条件里的 id 值），所以单靠它无法确认是否误删某条特定记录，必须和 binlog 联查
- 开启 audit plugin 有性能损耗（尤其高并发短连接场景），而 binlog 开销已在主库复制链路上摊平，除非你关了 binlog，否则优先依赖它
- Percona Server 的
audit_log支持audit_log_policy=ALL+audit_log_include_accounts，但日志是 JSON 格式文本，grep 查"query":"DELETE FROM users WHERE id=123"很方便；不过生产环境若没提前开，就只剩 binlog 这一条路
最常被忽略的一点：binlog 中的 DELETE_ROWS_EVENT 不包含 SQL 语句原文，只存变更前的行镜像 —— 所以你永远不知道应用层发的是 DELETE FROM t WHERE id=123 还是 DELETE FROM t WHERE status='old'，只能靠 WHERE 条件字段是否出现在镜像里来推测。这点决定了逆向分析的边界。
