Navicat 不提供 SQL 脚本执行的实时进度条，仅显示“正在运行”或最终结果；进度需通过日志滚动、数据库侧查询（如 SHOW PROCESSLIST 或 pg_stat_activity）及脚本埋点等方式人工估算。
Navicat 本身不提供 SQL 脚本执行的实时进度条
它把整个 .sql 文件当作一批语句顺序提交，执行窗口只显示“正在运行”或最终成功/失败提示，不会告诉你“已执行 12,483/50,000 行”。所谓“实时监控”，其实是靠日志滚动 + 数据库侧反查拼凑出来的。如果你指望 Navicat 自带一个百分比进度条，那得立刻切换思路。
怎么让 Navicat 显示执行过程中的关键日志
默认情况下，Navicat 执行 SQL 文件时是静默的——哪怕中间卡住、报错、跳过某条语句，也不会主动弹窗或高亮。必须手动开启日志输出：
- 右键目标数据库 →
Execute SQL File - 选中脚本后，勾选底部的
Show log window（不是“高级”里的那个） - 确保
Continue on error已启用 —— 否则遇到第一条错误就停，你根本看不到后续执行到哪了 - 注意日志里出现的
Executing statement #1245或Query OK, 1 row affected这类行，它们是唯一能帮你估算进度的线索
为什么 Navicat 日志停了，但数据库还在忙
常见现象：日志窗口停止滚动超过 20 秒，Navicat 界面仍显示“正在运行”。这通常说明执行已进入数据库内核层，Navicat 客户端失去了控制权：
- MySQL 场景下，去另一个会话执行
SHOW PROCESSLIST，盯住State列：若为Updating、Sending data或Writing to net，说明语句还在跑；若为Locked或长时间Waiting for table metadata lock，大概率是 DDL 阻塞了 - PostgreSQL 场景下，查
pg_stat_activity，过滤state = 'active'且query ~ 'your_table_name'，看backend_start和state_change时间差是否异常大 - 别信 Navicat 的“取消”按钮 —— 它发的是客户端中断请求，对已下发到数据库的长事务基本无效；真要停，得直接在数据库侧
KILL对应线程
真正可控的进度监控必须绕过 Navicat
当脚本含大量 INSERT/UPDATE 或跨表操作时，最可靠的方式是提前埋点 + 数据库侧验证：
- 在原始 SQL 脚本里，每隔 1000 行插入一条带时间戳的注释，例如：
-- PROGRESS: processed 1000 rows at 2026-09-07 19:10:22，执行时这些注释虽不执行，但 Navicat 日志会照常打印出来 - 如果脚本操作的是单张大表，执行前先在目标库跑一次
SELECT COUNT(*) FROM table_name记下基数；执行中定期再查，对比增长量估算进度 - 对 MySQL，启用
general_log并设log_output = 'TABLE'，然后查mysql.general_log表，可看到每条实际执行的语句（注意性能开销） - Navicat 的日志只缓存在内存里，关闭连接即清空；如需长期留存，务必在执行前用
SET GLOBAL general_log = ON配合文件输出，否则事后无从追溯
真正的进度感知不在客户端界面里，而在你是否愿意多开一个终端、多查一次系统表、或多加一行注释。工具只是通道，监控逻辑得自己写进去。
