先确认 mysql 是否启用 binlog：检查配置文件有无 log-bin 行，再执行 show variables like 'log_bin' 验证返回 on；未启用则无法回滚。
确认 MySQL 是否启用了 binlog
没开 binlog，就根本没法回滚；很多宝塔新装环境默认关闭。别急着翻日志，先看配置是否生效。
- 进宝塔 → 数据库 → 点击对应 MySQL 实例右侧的 设置 → 查看
配置文件里是否有log-bin开头的行（比如log-bin = /www/server/data/mysql-bin） - 如果没有，要手动添加并重启 MySQL；注意路径权限得是
mysql用户可写，否则启动失败 - 即使配置写了，也得验证是否真启用：
mysql -u root -p -e "SHOW VARIABLES LIKE 'log_bin';"，返回ON才算数 - 常见坑：宝塔升级后重置了配置文件，或者用“一键部署”装的 MySQL 被精简掉了 binlog 支持
定位误删操作发生的时间点和 binlog 文件
binlog 是按时间顺序追加写的，但不是每个文件都含你要找的操作——得先缩小范围，不然解析几 GB 日志会卡死。
- 查最近的 binlog 列表：
mysql -u root -p -e "SHOW BINARY LOGS;" - 用
mysqlbinlog检查具体文件内容，重点看DROP DATABASE或DROP TABLE前后的timestamp和end_log_pos：mysqlbinlog --base64-output=DECODE-ROWS -v /www/server/data/mysql-bin.000005 | grep -A2 -B2 "DROP TABLE\|DELETE FROM\|TRUNCATE" - 注意时区：宝塔服务器时间、MySQL 的
system_time_zone、日志里记录的 timestamp 可能不一致，建议统一用 UTC 或直接比对end_log_pos - 如果误删发生在很久以前，而 binlog 已被自动清理（
expire_logs_days默认 0 或 7），那就只能从最近一次全量备份恢复了
用 mysqlbinlog 提取并过滤出误删前的 SQL
直接回放整个 binlog 风险极大，必须精确截取“删之前、增之后”的那段事务，否则可能把后续正常数据也覆盖掉。
- 推荐用起止 position 方式提取：
mysqlbinlog --start-position=12345 --stop-position=67890 /www/server/data/mysql-bin.000005 > restore.sql - 如果知道大概时间，可用
--start-datetime和--stop-datetime，但要注意格式必须是'2024-05-20 14:23:01'，且 MySQL 服务端时区要匹配 - 务必加
--database=your_db_name参数过滤库名，避免跨库误操作混入 - 生成的
restore.sql里可能包含SET @@SESSION.GTID_NEXT这类复制语句，如果不在主从环境，用--skip-gtids参数跳过，否则执行时报错
执行恢复并验证数据完整性
恢复不是执行完就完事，MySQL 不会主动告诉你哪条 INSERT 因主键冲突被跳过，得自己盯住输出和数据状态。
- 先在测试库或同名库的副本上试跑：
mysql -u root -p your_db_name - 观察命令行输出：如果有
ERROR 1062（重复键）、ERROR 1146（表不存在）这类报错，说明日志里有依赖缺失，得人工补建表或调整顺序 - 别只查行数，要抽样核对关键字段值，尤其是时间戳、金额、状态字段——binlog 回放的是原始语句，如果原操作用了
NOW()或UUID()，回放时会生成新值 - 宝塔自带的“phpMyAdmin”不适合执行大 SQL，容易超时或截断，坚持用命令行
binlog 恢复本质是“重放历史”，它不管业务逻辑是否合理；比如你删表前刚改过配置表，但恢复时漏了那条 UPDATE，数据就处于矛盾状态。这种细节，没人能替你判断。
