navicat 15 不支持精确到秒级的时间点恢复，仅能还原其生成的 .psc 备份快照（粒度为备份执行完成时刻），真要恢复至指定时间点（如2026-07-27 14:23:18）必须依赖 mysql 的 binlog，通过 mysqlbinlog 工具按时间范围解析并重放，前提为 binlog 已启用且未过期。
navicat 15 本身不支持直接按时间点恢复数据，必须依赖 mysql 的 binlog + 手动解析，navicat 只能还原整个备份文件或指定对象（表/视图等），不能跳到某秒某毫秒。
Navicat 15 能做的“时间点”仅限于备份快照
Navicat 的 还原备份 功能只认它自己生成的 .psc 文件，每个备份对应一个固定时刻的全量或增量快照。你选中某个备份，就只能还原到那个时刻的状态——没有“2026-07-27 14:23:18”这种粒度。
- 备份列表里显示的时间，是 Navicat 执行
Backup命令完成的那一刻，不是数据库内事务提交时间 - 如果你设置了每小时自动备份，那最细粒度就是 1 小时，中间删掉的数据无法单独捞回
- 右键备份 →
还原备份→ 切换到对象选择标签页，可勾选部分表，但仍是该备份时刻的全部数据，不是“只恢复某张表在昨天 15:00 的状态”
真要恢复到指定时间点，得绕开 Navicat 直接用 mysqlbinlog
前提是：MySQL 已启用 binlog，且日志未被清理（expire_logs_days 设置合理），并且你知道误操作发生的大致时间范围。
- 先查日志列表：
SHOW BINARY LOGS; - 定位起止位置或时间：
mysqlbinlog --base64-output=decode-rows -v mysql-bin.000003 | grep -A 5 -B 5 "DELETE FROM my_table" - 按时间恢复（推荐）：
mysqlbinlog --start-datetime="2026-07-27 14:20:00" --stop-datetime="2026-07-27 14:23:18" mysql-bin.000003 | mysql -u root -p mydb - 注意：恢复前务必停写，或导出当前库为临时副本再操作，否则可能把新数据冲掉
为什么 Navicat 不提供时间点恢复界面
这不是功能缺失，而是设计取舍。binlog 解析和应用涉及事务边界、GTID、行格式（ROW/STATEMENT）、冲突判断等复杂逻辑，GUI 工具强行封装容易出错。Navicat 把这部分交还给 DBA 或运维脚本更稳妥。
- Navicat 的
任务→新建批处理作业只能调用Backup，不能调用mysqlbinlog - 即使你用 Navicat 导出 SQL（
转储 SQL 文件），它也只含 DDL+INSERT，不含 DELETE/UPDATE 的逆向逻辑，无法用于时间点回退 - 所谓“还原到某时间点”，本质是重放 binlog 中该时间段内的所有语句（跳过误删那条），这一步必须人工校验 SQL 内容，不能全自动信任
真正容易被忽略的点是：binlog 恢复不是“撤销删除”，而是“重放删除前的所有变更”。如果误删发生在上午，而你下午才想起恢复，期间又有大量写入，这些新数据会和恢复语句一起执行，大概率引发主键冲突或唯一索引报错——得提前用 --exclude-gtids 或过滤掉无关库表，而不是直接管道进 mysql。
