navicat“运行sql文件”卡在99%不是真卡，而是进度估算失效：因客户端仅粗略扫描分号计数，遇注释/字符串/存储过程内分号或bom头即导致分母失准，实际仍在执行；应等待完成或改用mysql命令行导入。
Navicat“运行SQL文件”卡在99%不是真卡，而是进度估算失效
Navicat 显示“99%”后长时间不动，大概率不是 MySQL 没在执行，而是它自己放弃了进度计算——底层用简单分号计数预估总行数，一旦遇到注释里的分号、字符串中的分号、BOM头或存储过程体内的分号，分母就崩了。比如预估 1000 行，实际有 5 万行，跑到第 49500 行时显示 99% 就停住，其实还在跑。
这种现象在含 DELIMITER $$、/*!40101 SET 或大量 JSON 字段的 SQL 文件里特别常见。Navicat 不解析语法，只扫分号，所以你改语句逻辑没用，得绕过它的估算机制。
- 别盯着进度条刷新或重试，继续等——只要 MySQL 连接没断、
SHOW PROCESSLIST里还有Query状态，说明还在执行 - 打开另一个查询窗口，执行
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query';，确认是否有活跃导入线程 - 用命令行连上去看真实进度：
mysql -u root -p -e "SHOW PROCESSLIST;" | grep "INSERT\|LOAD"
卡在99%时强行中断会丢数据，必须等它自然结束或换路径
点“停止”按钮大概率无效：Navicat 主线程已被阻塞，GUI 无法把取消信号传给 MySQL。更糟的是，如果当时正处在事务中间（尤其你勾了「手动提交」），中断可能留下部分写入+未提交状态，导致后续导入主键冲突或重复数据。
真正安全的做法只有两个：
- 保持 Navicat 窗口开着，不操作、不关机，让它跑完——哪怕显示 99% 十分钟，实际可能只剩最后几万行 INSERT
- 立刻切到命令行，用
mysql -u root -p your_db 重新导入（需先 <code>DROP DATABASE或清空表）
注意：不要用 source 命令在 Navicat 查询窗口里执行大文件，它仍走客户端解析，一样会卡在 99%。
下次导入前必须做的三件事，避免再卡99%
卡在 99% 是症状，根源是 Navicat 对 SQL 文件结构缺乏容忍力。以下操作不能省：
- 删掉所有
/*!40101 SET开头的注释行——Navicat 批量执行器会把它当非法语法截断 - 用 VS Code 或 Notepad++ 把文件编码转为 UTF-8 无 BOM，否则首行读取失败会导致计数初始化为负值
- 确认目标 MySQL 版本（执行
SELECT VERSION();），然后在 Navicat 「工具 → 选项 → MySQL → 兼容性模式」中**手动选中该版本**，不能留空或选“自动”
做完这三项，Navicat 的进度条未必变准，但至少不会在 99% 假死——它会跳到 102%、150%，甚至直接完成。因为此时它已放弃估算，只等服务端返回 OK。
真正要盯的不是进度条，是 MySQL 的 innodb_buffer_pool_wait_free 和磁盘 I/O
如果你反复遇到“卡住”，别调 Navicat 设置，先查 MySQL 本身：
- 执行
SHOW ENGINE INNODB STATUS\G，看SEMAPHORES段是否频繁出现wait for buffer pool mutex - 用
iostat -x 1观察%util是否持续 100%，说明磁盘写不过来 - 检查
innodb_log_file_size：若单个 INSERT 批次超 256MB，可能触发日志轮转阻塞
Navicat 的 99% 只是界面层幻觉；MySQL 内部是否卡住，得看服务端指标。很多所谓“卡死”，其实是磁盘写满、buffer pool 溢出或网络包被截断，和进度条数字毫无关系。
