MySQL连接数超限表现为“Too many connections”，需先查max_connections、Threads_connected及PROCESSLIST识别Sleep/Query/Locked等异常连接，再Kill或调参优化。
查看当前连接数和最大连接限制
MySQL 连接数超限最直接的表现是客户端报错 Too many connections。先确认实际连接数和配置上限，避免误判：
- 执行
SHOW VARIABLES LIKE 'max_connections';查看允许的最大并发连接数（默认通常为 151） - 执行
SHOW STATUS LIKE 'Threads_connected';获取当前活跃连接数 - 执行
SHOW PROCESSLIST;或SELECT * FROM information_schema.PROCESSLIST;查看具体连接来源、状态、运行时长
注意：普通用户可能无权查 information_schema.PROCESSLIST，需用有 PROCESS 权限的账号（如 root）。
识别长连接、空闲连接和异常连接
大量 Sleep 状态连接常是应用未正确关闭连接导致的；而长时间 Query 或 Locked 状态则可能卡在慢查询或锁等待上。
-
Sleep状态且Time值很大（比如 > 300 秒）：大概率是应用端连接池未回收、或设置了过长的wait_timeout/interactive_timeout -
Query状态持续数分钟以上：用SHOW FULL PROCESSLIST;看 SQL 内容，结合EXPLAIN分析是否缺少索引或存在全表扫描 -
Locked或Waiting for table metadata lock：说明被 DDL（如ALTER TABLE）阻塞，需检查是否有长事务或未提交事务
临时释放连接与调整配置
紧急情况下需快速释放资源，再考虑长期优化：
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 手动 Kill 异常连接：
KILL <code>id;（id来自SHOW PROCESSLIST输出），慎杀system user或主从复制线程 - 临时调高上限（仅限应急）：
SET GLOBAL max_connections = 500;，但该值不能超过max_connections的编译上限，且重启后失效 - 缩短空闲连接超时：
SET GLOBAL wait_timeout = 60;和SET GLOBAL interactive_timeout = 60;，让闲置连接更快释放
这些 SET GLOBAL 操作需 SUPER 权限，且不建议设得过低（如
应用层连接池与 MySQL 配置协同优化
单纯调大 max_connections 是治标，连接泄漏或低效使用才是根源。关键要对齐应用连接池参数与 MySQL 超时设置：
- 若用 HikariCP，确保
connection-timeoutwait_timeout，且idle-timeout和max-lifetime合理（例如分别设为 300000 和 1800000） - 若用 Druid，检查
minIdle是否过高、removeAbandonedOnBorrow是否启用，避免连接堆积 - MySQL 配置文件中应持久化设置：
max_connections = 300 wait_timeout = 300 interactive_timeout = 300
，并重启 mysqld 生效 - 务必监控连接数趋势（如通过 Prometheus + mysqld_exporter），而不是等报警才介入
很多问题其实出在「应用没 close()，MySQL 又等太久才断」——两边超时没对齐，是最容易被忽略的协同盲区。
