结论：调大max_connections前须先排查连接泄漏、慢查询或连接池配置问题；真要调整，需同步降低wait_timeout并启用线程池（Percona/MariaDB原生支持），否则将导致“全卡死”。
直接说结论：别急着调大 max_connections，先确认是不是连接泄漏、慢查询堆积或连接池配置失当；真要调，也得同步压低 wait_timeout 和启用线程池，否则只是把问题从“连不上”变成“全卡死”。
怎么快速确认是真爆满还是假拥堵
登录 MySQL 后立刻执行这三条命令，顺序不能错：
-
SHOW VARIABLES LIKE 'max_connections';—— 看上限是多少（默认 151，云数据库常设 1000+） -
SHOW STATUS LIKE 'Threads_connected';—— 看当前活连接数，接近上限就是真爆满 -
SHOW PROCESSLIST;—— 重点看状态列：Cleaning up多说明查询执行完但没归还连接；Sleep且时间超长（比如 >300 秒）大概率是应用端没 close；Query卡在Sending data或Copying to tmp table就是慢 SQL 在拖住连接
临时救急：不重启也能松绑，但有风险
如果业务已阻塞，优先用运行时调整，但必须搭配清理动作：
- 执行
SET GLOBAL max_connections = 2000;—— 注意：该值受物理内存限制，每连接约吃 2–3MB 内存，16GB 机器别轻易设超 1000 - 立刻执行
SET GLOBAL wait_timeout = 60;和SET GLOBAL interactive_timeout = 60;—— 让空闲连接 60 秒后自动断开，比干等 8 小时强得多 - 对明确可杀的长事务，用
KILL QUERY <code>id;（不是KILL <code>id），避免中断连接导致应用重连风暴
⚠️ 这些 SET 命令只在本次实例生命周期有效，重启就还原。别依赖它长期扛压。
MySQL 8.0+ 必开连接管理接口（admin_port）
当 max_connections 被占满，普通账号连都连不进去，管理员也进不去——这是最致命的盲区。MySQL 8.0 引入了独立管理通道：
- 检查是否启用：
SELECT @@admin_address, @@admin_port, @@create_admin_listener_thread;—— 返回1表示已开 - 若未启用，在
my.cnf的[mysqld]段加：admin_address=127.0.0.1和admin_port=33062 - 重启后，用
mysql -h 127.0.0.1 -P 33062 -u root -p即可绕过连接数限制直连，查PROCESSLIST或杀会话
这个端口不走常规连接池逻辑，也不计入 max_connections，是 DBA 的保命通道，别等出事才配。
线程池不是万能药，Percona/MariaDB 才原生支持
官方 MySQL 社区版（5.7/8.0）**不带线程池**，所谓 thread_pool_size 是插件参数，需手动安装；而 Percona Server 和 MariaDB 默认内置且更稳定：
- Percona 中启用只需在
my.cnf加：thread_handling = pool-of-threads和thread_pool_size = 4（建议设为 CPU 核数） - 线程池本质是复用线程处理多个连接请求，能显著降低上下文切换开销，但对单个慢查询无加速作用
- 如果用的是官方 MySQL，别折腾线程池插件——优先优化连接池配置（如 Druid 的
max-active）和 SQL，效果更实在
真正容易被忽略的点：max_connections 调高后，innodb_buffer_pool_size 往往没同步扩容，导致大量磁盘 I/O，系统负载不高但响应极慢——这正是很多“连接数满了但 CPU 很低”的真实原因。
