Navicat执行脚本报“无法启动查询”并非连接池满（Navicat无连接池概念），而是MySQL服务端max_connections耗尽或连接卡在Cleaning up等状态；可通过SSH执行SHOW VARIABLES和SHOW PROCESSLIST确认，紧急缓解需关闭闲置窗口、设sql_select_limit、避免全表扫描脚本，根本解决需调优innodb_buffer_pool_size、timeout参数并必要时重启实例。
Navicat执行脚本报“无法启动查询”是连接池满了？
不是。navicat本身没有“连接池”概念，它只是客户端工具，每次新建查询窗口默认建立一个独立连接。所谓“无法启动查询”，绝大多数情况是mysql服务端的max_connections已耗尽，或者当前连接被阻塞、卡在cleaning up状态——这时navicat发不出新请求，就显示这个模糊提示。
怎么确认是不是MySQL连接数打满了
直接连上数据库服务器（SSH），用命令查：
mysql -u root -p -e "SHOW VARIABLES LIKE 'max_connections'; SHOW STATUS LIKE 'Threads_connected';"
如果Threads_connected接近或等于max_connections，基本就是它了。再补一句：
mysql -u root -p -e "SHOW PROCESSLIST;" | head -20
重点看状态列：Sleep太多说明应用没释放连接；Cleaning up或Killed堆积，大概率是Buffer Pool太小+大查询反复刷脏页，导致连接卡住不退出。
Navicat侧能做的紧急缓解动作
别急着调大MySQL参数，先让Navicat“喘口气”：
- 关闭所有闲置的查询窗口（每个窗口=1个连接，关掉就释放）
- 在当前连接里手动执行：
SET @@SESSION.sql_select_limit = 1000;，防止后续查询拖垮连接 - 避免使用“全部执行”按钮跑含
UNION多表全扫的脚本——这类SQL极易触发连接长时间占用 - 换用命令行
mysql客户端执行脚本，它对连接异常更敏感，失败时会明确报Too many connections
真正要改的是MySQL服务端配置
光调max_connections治标不治本。结合你知识库里那个电商案例，关键其实是innodb_buffer_pool_size设得太低（比如128M），而数据量几十GB，结果MySQL疯狂换页、锁等待、连接卡死。必须同步调整：
-
innodb_buffer_pool_size建议设为物理内存的50%~75%，但不超过max_connections × 2MB（避免单连接内存开销反噬） -
wait_timeout和interactive_timeout设成120~300秒，防Sleep连接长期占坑 - Percona/MariaDB用户可临时用
extra_port登录救急，但别依赖它长期扛压
缓冲池在线扩容在连接风暴中容易卡住，重启实例仍是最快恢复手段——这点容易被忽略，但线上稳态比“不重启”的执念重要得多。
