binlog必须开启并保留足够久，检查log_bin、binlog_format=ROW、expire_logs_days≥还原所需天数；用mysqlbinlog定位目标时间点的文件名和position；回放时优先用--start-position与--stop-position，过滤误操作需删###块而非简单grep。
binlog 必须开启且保留足够久
MySQL 默认不启用 binlog，还原到某秒的前提是它开着，而且日志没被自动清理掉。检查 my.cnf 或 mysqld.cnf 里有没有这三行：
-
log_bin = /var/lib/mysql/mysql-bin（路径可自定义，但必须存在且 MySQL 有写权限） -
binlog_format = ROW（强烈推荐，STATEMENT在某些函数或非确定性语句下无法精确还原） -
expire_logs_days = 7（至少覆盖你要还原的时间点，比如要回退到 3 天前，就得 ≥3）
改完记得重启 MySQL，并用 SHOW VARIABLES LIKE 'log_bin'; 和 SHOW MASTER LOGS; 确认生效。如果 log_bin 是 OFF，或者 SHOW MASTER LOGS 返回空，后面所有操作都白搭。
定位目标时间点对应的 binlog 文件和位置
不能靠猜，得用 mysqlbinlog 解析日志找精确位置。先查出大概哪几个文件覆盖了那个时间点：
mysqlbinlog --base64-output=decode-rows -v /var/lib/mysql/mysql-bin.000012 | grep -A 2 -B 2 "2024-05-20 14:23:45"
注意：时间格式必须严格匹配 binlog 中的 # at 行时间戳（默认是本地时区，不是 UTC）。更稳的方式是先用 mysqlbinlog --no-defaults --base64-output=decode-rows -v mysql-bin.000012 | head -20 看开头时间，再逐个扫描。找到后记下两个关键信息：
- 文件名，比如
mysql-bin.000012 - 对应时间点前最后一个
# at 123456的偏移量（不是时间戳本身）
别直接用 --stop-datetime，它在跨文件边界时可能截断不完整；优先用 --start-position + --stop-position 组合。
用 mysqlbinlog 回放时跳过误操作语句
如果你知道误操作是哪条 SQL（比如 DELETE FROM orders WHERE status='pending';），最安全的方式不是全量回放，而是过滤掉它：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
mysqlbinlog --base64-output=decode-rows -v --start-position=123456 --stop-position=789012 mysql-bin.000012 | grep -v "DELETE FROM orders" | mysql -u root -p
但要注意：grep -v 只适合简单匹配，ROW 格式下实际变更藏在 ### UPDATE 块里，此时得用 --exclude-gtids 或先解析成 SQL 再人工删。更可靠的做法是：
- 用
mysqlbinlog --base64-output=decode-rows -v --start-position=123456 mysql-bin.000012 > replay.sql导出为文本 - 用编辑器打开，搜索误操作的
### DELETE或### UPDATE块，整块删掉（包括前后###分隔行） - 执行
mysql -u root -p
别忘了加 --database=myapp 参数限制只处理目标库，避免误刷其他库。
还原后主从同步和 GTID 的坑
如果数据库开了主从，直接回放 binlog 很可能让从库报错（比如主键冲突、找不到表）。先停掉从库复制：STOP SLAVE;，还原完再手动调整 CHANGE MASTER TO MASTER_LOG_FILE='mysql-bin.000012', MASTER_LOG_POS=789012;，然后 START SLAVE;。GTID 模式下更麻烦——你不能随便指定 position，得用 SET GLOBAL gtid_purged = 'xxx-yyy-zzz:1-1000'; 清理掉已应用但不该存在的事务，否则 START SLAVE 会拒绝启动。这个值必须从 SHOW MASTER STATUS 和 SELECT * FROM mysql.gtid_executed; 交叉比对得出，差一位都会失败。
真正难的从来不是“怎么执行命令”，而是确认那条 # at 位置是否真的在误操作之前、是否跨了事务边界、以及 GTID 集合有没有被意外污染。这些细节一错，还原出来的数据表面看着对，实际已经坏了。
