navicat还原sql文件进度条显示负数或1000%+是因客户端粗略扫描分号计数失准所致：bom头导致初始计数异常、注释/字符串/存储过程中分号被误判，而“运行sql文件”走服务端执行可彻底规避该问题。
navicat 还原 sql 文件时进度条显示负数或 1000%+ 怎么回事
这不是数据库出错，也不是 navicat 崩溃，而是它在“估算行数”时被 sql 文件里的注释、空行、多语句分号、长字符串中的分号给骗了。navicat 不解析语法，只靠粗略扫描 ; 来计数，一旦统计失准，进度分母就崩了——比如预估 50 行，实际有 2000 行，进度就会跳到 400%；更糟的是，若文件开头有 bom 或乱码导致首行读取失败，某些版本会把初始计数设为负值，直接显示 -27%。
哪些 SQL 内容会让 Navicat 行数统计彻底失效
以下结构会干扰 Navicat 的简单分号计数逻辑，且无法通过设置绕过：
- 单行注释里带分号：
-- INSERT INTO t VALUES (1, 'a;b');→ 被当成两条语句 - 多行字符串含未转义分号：
INSERT INTO t VALUES ('foo;bar');→ 分号被误判为语句结束 - 存储过程/函数体内的分号：
BEGIN ... END;中每个分号都计入，但实际只算一个CREATE PROCEDURE语句 - 文件开头存在 UTF-8 BOM（
EF BB BF）→ 部分 Navicat 版本读取首行失败，行计数初始化异常 - 混合语句块用
DELIMITER改变结束符，但 Navicat 完全忽略该指令，仍硬扫分号
不用改 SQL 文件，怎么让进度条回归正常
根本解法是绕过 Navicat 的客户端行数预估，改走服务端执行：
- 别用「查询」窗口粘贴执行大 SQL：它依赖客户端逐行解析，进度必然失真
- 改用右键连接 → 运行 SQL 文件：此模式将整个文件发给 MySQL 服务端执行，Navicat 只接收最终结果，不参与行数统计
- 确认 Navicat 设置中「工具 → 选项 → MySQL → 查询」里勾选了 允许执行多个查询（否则遇到第一个分号就停）
- 如果必须用「查询」窗口调试，先手动删掉文件头部 BOM（用 VS Code 或 Notepad++ 切换编码为 UTF-8 无 BOM）
为什么不能指望 Navicat 修复这个问题
这不是 bug，是设计取舍。Navicat 的进度条本质是客户端对文件的轻量预扫描，目标是快速反馈而非精确匹配。真正可靠的进度监控只能来自服务端——比如用 mysql --verbose 命令行执行时输出的 Query OK, X rows affected，或在慢查询日志里看实际执行耗时。你看到的负数，只是它放弃估算后返回的默认异常值，继续等下去，只要 SQL 本身合法，最终还是会执行完。
