Navicat查询超时本质是客户端执行层主动中断，优先级高于服务端配置；需先禁用Navicat“查询超时（秒）”设为0，若仍失败再排查MySQL的wait_timeout、interactive_timeout及max_execution_time等服务端参数。
Navicat 查询超时是连接层还是执行层的问题？
“查询超时”在 navicat 中通常不是 sql 本身报错，而是客户端主动中断了等待——它默认用的是 mysql 的 wait_timeout 和 interactive_timeout 配置，但更常见的是 navicat 自己的「查询超时（seconds）」设置在作祟。这个值独立于数据库服务端配置，优先级更高。
实操建议：
- 打开 Navicat → 工具 → 选项 → 连接 → 将「查询超时（seconds）」设为
0（表示禁用客户端超时），这是最直接的排查手段 - 如果设为
0后仍失败，说明问题出在服务端：检查 MySQL 的wait_timeout值（SHOW VARIABLES LIKE 'wait_timeout';），若低于 60，长期空闲连接会被服务端主动断开 - 注意：Navicat 的「连接超时」（Connection timeout）和「查询超时」（Query timeout）是两个独立开关，前者控制建立 TCP 连接的等待时间，后者控制 SQL 执行的最大等待时长
为什么改了 Navicat 超时设置，大查询还是被杀？
因为某些场景下，Navicat 会忽略全局设置，只认当前连接的「高级」配置。特别是通过 SSH 隧道、HTTP 隧道或代理连接时，超时逻辑可能被重载。
实操建议：
- 右键已保存的连接 → 编辑连接 → 切换到「高级」页签 → 找到「查询超时（秒）」，手动设为
0或一个较大值（如300） - 如果使用「查询」窗口执行语句，点击右上角齿轮图标 → 勾选「不使用查询超时」，这个设置仅对当前查询窗口生效
- 避免在「批处理」模式下运行长时间任务：批处理默认启用超时且不可关闭，应改用「查询」窗口或导出为 SQL 文件后用命令行执行
MySQL 服务端 timeout 相关参数怎么配合调整？
单纯调高 Navicat 超时治标不治本。比如一个需要 120 秒的导出操作，若 MySQL 的 max_execution_time（MySQL 5.7.8+）设为 60，SQL 还是会在服务端被强制终止，Navicat 收到的是 Query execution was interrupted 错误，而非超时提示。
实操建议：
- 临时绕过执行时间限制：在查询前加
SET SESSION max_execution_time = 0; - 检查并调高关键参数：
wait_timeout（非交互式连接）、interactive_timeout（交互式连接，Navicat 默认走这条）、net_read_timeout（读取响应超时） - 修改方式：在 MySQL 配置文件（
my.cnf或my.ini）的[mysqld]下添加，例如：wait_timeout = 28800<br>interactive_timeout = 28800<br>net_read_timeout = 600
，改完需重启 MySQL
超时错误里混着「Lost connection to MySQL server during query」怎么办？
这个错误看似是网络问题，实际大概率是 Navicat 在等待结果时，服务端因内存不足、OOM Killer 杀进程、或磁盘满导致连接静默中断。此时查 SHOW PROCESSLIST; 会发现对应线程状态是 NULL 或已消失。
实操建议：
- 先看 MySQL 错误日志（路径由
log_error变量决定），搜索关键词Aborted connection或Killed - 检查系统资源：
free -h、df -h、dmesg | grep -i "killed process" - 如果是大数据量导出，别用 Navicat 的「导出向导」：它会把整张表加载进内存再写文件，改用「转储 SQL 文件」功能（本质是
mysqldump），或直接命令行执行SELECT ... INTO OUTFILE
