需启用binlog_rows_query_log_events=ON，用mysqlbinlog -v解析Query事件，从中提取# User@Host注释行获取执行者IP和用户名，同时确认sql_log_bin未被禁用且binlog未过期。
怎么从 binlog 里定位 delete database 操作
MySQL 本身不记录“谁删了库”这种审计级操作，DROP DATABASE 在 binlog 中只体现为一条 Query 事件，不含用户信息。必须结合 binlog_format = ROW 或 MIXED 下的附加上下文（比如执行线程 ID、时间戳、host）反推，且前提是开启了 log_bin 和 binlog_rows_query_log_events = ON（后者让 ROW 模式下也保留原始 SQL）。
关键点：DROP DATABASE 不会写入表数据变更，所以即使在 ROW 模式下也不会产生 Table_map / Write_rows 事件，只能靠 Query 类型事件抓取。
-
mysqlbinlog --base64-output=DECODE-ROWS -v是必备参数，否则看不到原始 SQL 和线程信息 - 搜索
DROP DATABASE要注意大小写和空格变体，比如DROP\nDATABASE或带反引号的`db_name` - 时间精度到秒，但 binlog 事件里的
timestamp是 Unix 时间戳，需用date -d @1712345678转换
如何提取执行者 IP 和用户名
binlog 的 Query 事件本身不存 user@host，但 MySQL 5.7.2+ 在启用 log_bin_trust_function_creators = OFF 且开启 binlog_rows_query_log_events 时，会在事件末尾附带 # User@Host: 注释行——这是唯一能直接看到操作来源的地方。
示例输出片段：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
# User@Host: app_user[app_user] @ 10.20.30.40 [10.20.30.40] Id: 12345 # Query_time: 0.000123 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0 use `test_db`; DROP DATABASE `old_schema`;
- 必须确保
binlog_rows_query_log_events = ON，否则该注释不会写入 binlog -
User@Host中的 IP 是客户端连接时声明的，可能被代理或 NAT 修改，不一定等于真实出口 IP - Id 字段是当时连接的线程 ID，可结合
performance_schema.threads表查更早的 account、program_name 等信息（需提前开启相关 instrumentation）
为什么有时候查不到 DROP DATABASE 记录
不是所有 DROP DATABASE 都会被记录进 binlog，常见漏掉场景：
- 当前 session 设置了
sql_log_bin = 0，该语句完全绕过 binlog - 使用
mysqladmin drop db_name命令，底层仍是发送DROP DATABASE，但若连接未启用 binlog 或权限不足，也会静默失败 - binlog 文件已被 purge（
PURGE BINARY LOGS），或 MySQL 启动时配置了expire_logs_days自动清理 - 数据库名含特殊字符（如短横线、中文）且未加反引号，导致解析失败，
mysqlbinlog可能跳过整条事件
验证是否真没记录：先用 SHOW BINARY LOGS 查最新 binlog 名，再用 mysqlbinlog 扫描全部文件，别只盯最后一个。
替代方案：用 general_log 做实时审计（慎用）
如果 binlog 已丢失或配置不满足，general_log 是唯一能拿到完整 user@host + timestamp + SQL 的方式，但它代价极高：
- 每条语句都写磁盘，QPS 高时 I/O 成瓶颈，线上环境基本不可开
- 日志格式是纯文本，无结构化字段，grep 提取成本高，且无法回溯已滚动的日志
- 默认只记录到文件，若用
general_log_table = ON写入mysql.general_log，该表是 CSV 引擎，查询慢、锁表风险大
真正要长期做删除审计，得上 audit_log 插件（企业版）或 Percona Server 的 audit_log，或者用 performance_schema.events_statements_history_long 配合定期快照——但这些都不是 binlog 能解决的事。
