能恢复，但需先确认log_bin=ON且binlog_format=ROW；再用mysqlbinlog按时间或位置精准截取日志段，生成restore.sql并在测试库验证后执行，线上需加--skip-foreign-key-checks和--disable-log-bin。
恢复前必须确认 binlog 是否开启且为 ROW 格式
没开 log_bin 或格式是 STATEMENT，就只能靠全量备份硬恢复，RPO 动辄几小时——这不是恢复，是认栽。用 SHOW VARIABLES LIKE 'log_bin' 和 SHOW VARIABLES LIKE 'binlog_format' 两行命令必须先敲，结果得是 ON 和 ROW。如果发现是 MIXED 或 STATEMENT，立刻改配置、重启服务，别等出事再查。
用 mysqlbinlog 做精准时间点恢复，别直接回放整个 binlog 文件
误删发生在 2026-08-12 22:15:33？那就只提取那个时间点前的日志段，而不是把 mysql-bin.000042 全部导入。常用组合是：
mysqlbinlog --start-datetime="2026-08-12 22:15:00" --stop-datetime="2026-08-12 22:15:33" /var/lib/mysql/mysql-bin.000042 > restore.sql- 或用位置点更准：
mysqlbinlog --start-position=12345 --stop-position=67890 /var/lib/mysql/mysql-bin.000042 > restore.sql
生成的 restore.sql 先在测试库跑一遍，确认没混入其他表操作；线上执行时加 --skip-foreign-key-checks 和 --disable-log-bin，避免触发二次写入和循环复制。
物理备份恢复必须走从库或离线环境，禁止在主库上直接覆盖 data 目录
Percona XtraBackup 恢复出来的数据文件不能直接扔进运行中的主库 datadir。常见错误包括：
- 没停 MySQL 就解压备份到
/var/lib/mysql，导致 InnoDB 启动失败报错InnoDB: Database page corruption - 恢复后忘记执行
xtrabackup --prepare，直接启动，结果事务不一致、数据丢失 - 用
rsync同步时没加--delete和--exclude排除临时文件，把旧的ibtmp1或undo_001留了下来
正确路径：恢复到空闲服务器或从库节点 → 启动 MySQL → 验证数据一致性 → 再通过主从切换切流，主库全程不中断。
mysqldump 恢复时别忽略字符集与 SQL_MODE 差异
备份时用的是 utf8mb4，恢复目标库默认是 latin1？那中文全变问号。恢复前务必检查：
SELECT @@character_set_database, @@collation_database;-
SELECT @@sql_mode;（特别是STRICT_TRANS_TABLES开关会影响 INSERT 失败行为）
推荐显式指定恢复参数：mysql -u root -p --default-character-set=utf8mb4 mydb 。如果备份文件里没带 <code>SET NAMES，光靠客户端参数不够，得提前在目标库执行 ALTER DATABASE mydb CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;。
真正影响业务的从来不是恢复动作本身，而是恢复过程中对主库状态的误判、对 binlog 边界值的粗放处理、以及把“能跑通”当成“数据一致”的侥幸心理。ROW 格式日志 + 精确位置点 + 离线验证，这三件事漏掉任何一环，都可能让恢复变成二次事故。
