mysql命令行客户端无内置历史执行记录功能，仅依赖shell历史且不持久化；.mysql_history仅存输入命令，不记录结果或他客户端操作；需手动配置history文件、readline及启用general_log临时抓取全量语句。
mysql 命令行本身不存历史执行记录
别指望 mysql 客户端像 psql 那样用 \s 查会话命令历史——它根本没这功能。.mysql_history 文件只存你敲过的命令行（不含结果、不记执行成败），且默认不记录空行、反斜杠续行，异常退出时最后几条还常丢。Shell 的 Ctrl+R 搜的也是 shell 历史，不是 MySQL 内部执行流。
临时排查：用 general_log 抓全量语句
这是最接近“谁在什么时间干了什么”的原生方案，但仅限紧急排查，不能长期开着。
- 先确认状态：
SHOW VARIABLES LIKE 'general_log%'; - 临时启用：
SET GLOBAL general_log = ON;（重启后失效） - 日志默认写到
<code>general_log_file指向的文件（如/var/lib/mysql/hostname.log），可用tail -f实时观察 - 注意：它记录所有连接行为，包括
USE db、健康检查、甚至失败的登录尝试，噪音大 - 生产环境必须关掉：
SET GLOBAL general_log = OFF;
长期审计：二进制日志 + mysqlbinlog 是唯一可靠路径
如果你真要追溯数据变更（INSERT/UPDATE/DELETE）、定位误操作或还原攻击痕迹，binlog 是唯一带时间戳、事务上下文、客户端信息的官方机制。
- 确认已启用：
SHOW VARIABLES LIKE 'log_bin';—— 必须是ON - 查当前日志：
SHOW MASTER STATUS;，看File和Position - 解析指定时间段和库的操作：
mysqlbinlog --no-defaults --database=your_db --start-datetime="2026-06-30 10:00:00" --stop-datetime="2026-06-30 12:00:00" mysql-bin.000012 - 过滤敏感操作：
grep -E "(INSERT|UPDATE|DELETE|DROP|GRANT)"可辅助筛查，但别依赖它替代完整解析 - 注意：
binlog不记录 SELECT，也不记录未提交的事务；格式为ROW时能看到具体字段值，STATEMENT则只留 SQL 文本
别碰 Performance Schema 的 events_statements_history
这个表看起来像“历史记录”，实际是内存环形缓冲区，容量极小（默认 10000 行），只保留最近执行的语句片段，且重启清空、不持久、不带用户/IP/时间精度（只有微秒级开始时间）。它适合性能分析，不适合安全追踪——攻击者执行完就刷掉了，你根本捞不到。
真正要查安全隐患，核心就两条：一是立刻开 general_log 锁定窗口期抓现场，二是靠 binlog 回溯变更链。其他方案要么残缺，要么不可靠，要么代价高到没法用。
