启用异步查询是防止无响应的唯一有效手段，需升级至Navicat 17.0.4+并勾选「Enable asynchronous query execution」，且MySQL须用mysql-connector-j 8.0.33+驱动。
启用异步查询是防止无响应的唯一有效手段
navicat 17.0.4+ 版本才真正支持异步查询，v16 及更早版本无论怎么调配置，ui 线程都会被阻塞。这不是设置问题，而是架构限制——老版本所有 jdbc/odbc 调用都在主线程同步等待 recv() 返回完整结果集。
必须做两件事：升级到 Navicat 17.0.4 或更高版本，并在「首选项 → 查询」中勾选 Enable asynchronous query execution。该选项对 MySQL、PostgreSQL、Oracle、SQL Server 生效，但 SQLite 不支持。
- MySQL 必须使用
mysql-connector-j 8.0.33+驱动，否则仍会回退到同步模式 - 检查是否误启用了
Use legacy explain format，它会强制降级为同步解析 - 开启后，
EXPLAIN、DESCRIBE、SHOW CREATE TABLE等元数据操作也自动异步化
导出时别先执行再导出，直接点导出按钮
很多人习惯先点 运行 查看结果，再点 导出，这对大数据量反而是陷阱：结果网格渲染会占用大量内存和 UI 线程，极易触发崩溃或卡死。而 导出 动作本身是独立于结果展示的，Navicat 会绕过渲染层，直接从服务端流式拉取数据写入文件。
- 跳过
运行步骤，直接右键表名 →导出向导，或选中 SQL 后点击工具栏导出按钮 - 优先选
CSV格式而非Excel：前者无行数限制，且导出 100 万行约 203 秒；后者受 Excel 行上限1048576限制，超限直接失败 - 避免在导出前手动执行
SELECT *，尤其是宽表（列数 > 50）或大字段（如TEXT、BLOB）
分批次导出比“一次全量”更可靠
即使开了异步，导出两千万行仍可能因内存不足或网络波动中断。Navicat 17 的「数据传输」和「导出向导」都支持自定义批次大小，这是比“靠运气一次导完”更可控的做法。
- 在导出向导第 3 步选择「按记录数分批」，设为
100000（10 万条/批），避免单次加载过多到客户端内存 - 导出路径不要留在默认的
C:\Users\XXX\Desktop，改到空间充裕的盘符，比如D:\navicat_exports - 若导出中途卡在「已处理」字段不动，大概率是物理内存耗尽，此时立即点左下角
保存，能强制刷盘并释放部分缓存，继续后续批次 - 不推荐依赖
SELECT ... INTO OUTFILE：该语句需数据库服务器有写入权限，且路径由服务端决定，跨平台（如 macOS 客户端连 Linux 服务器）时易失败
导出目标位置和格式选错会放大失败概率
导出失败常被误判为“Navicat 问题”，实际是路径或格式引发的隐性瓶颈。例如 C 盘剩余空间不足 5GB 时，导出 2000 万行 CSV（预估 2–3GB）大概率在最后阶段因磁盘满而静默退出；又或者选了 Excel 格式却没意识到行数超限，导出到 1048576 行就停住且无提示。
- 导出前用
SELECT COUNT(*)确认总行数，若 > 100 万，直接排除Excel和HTML格式 - 路径尽量避开系统盘和含中文、空格、特殊符号的目录，例如不要用
C:\我的导出\数据，改用D:\export\batch_01 - 如果目标是后续用脚本处理，选
CSV并勾选导出列名和使用引号包围字段，兼容性最好
wc -l 或 PowerShell (Get-Content).Length），而不是只看 Navicat 的完成弹窗。 
