MySQL报错Too many connections的直接原因是当前活跃连接数超过max_connections配置值，而非SQL慢或内存不足；需通过SHOW PROCESSLIST定位空闲未释放连接，并合理配置连接池与超时参数。
MySQL报错Too many connections的直接原因
不是你SQL写得慢，也不是服务器内存不够——是当前活跃连接数超过了max_connections配置值。MySQL拒绝新连接时，会明确返回这个错误，而不是排队等待。
常见触发场景：wait_timeout或interactive_timeout设得过大（比如8小时），但应用没做连接复用，每次HTTP请求都新建连接、又不主动close()；或者连接池配置不合理，最大连接数远超MySQL允许上限。
查清谁在占着连接不放
别急着调大max_connections，先看连接到底在哪卡着：
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 执行
SHOW PROCESSLIST;，重点关注Command列为Sleep、Time值很大的行——这些是空闲但没断开的连接 - 用
SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 60;筛出挂了1分钟以上的空闲连接 - 检查
HOST列：如果是127.0.0.1:xxxxx这种带端口的，大概率是应用层没释放连接；如果是localhost，可能是本地脚本或定时任务漏关
应用层必须启用连接池 + 合理设置参数
长连接本身不是问题，问题是“连接建了不用、用了不放”。PHP/Python/Java等语言的MySQL客户端默认都不带连接池，得靠框架或中间件补上：
- Python用
pymysql时，别直接connect()，改用DBUtils.PooledDB或SQLAlchemy的create_engine(pool_size=5, max_overflow=10) - Node.js用
mysql2，必须显式传connectionLimit: 10，否则默认无限创建连接 - Java用HikariCP时，
maximumPoolSize不能盲目设高——它应 ≤ MySQL的max_connections减去系统保留连接（如复制线程、监控工具占用） - 所有连接池都要配
idleTimeout和maxLifetime，避免连接长期空闲却不被回收
wait_timeout和max_connections怎么设才不翻车
这两个值要配合调，单独改一个容易引发新问题：
-
wait_timeout建议设为60～300秒（5分钟），太短会导致连接池里的连接频繁被MySQL主动断开，下次取用时抛Lost connection to MySQL server during query -
max_connections别硬拍脑袋——先用SHOW STATUS LIKE 'Threads_connected';观察峰值，再留20%余量；超过500要警惕，可能暴露应用连接泄漏 - 如果业务确实需要大量并发连接（比如实时报表服务），优先考虑读写分离或分库，而不是把
max_connections调到2000+ - 注意：修改
max_connections需重启MySQL或用SET GLOBAL max_connections = 1000;（后者在某些云数据库上不生效）
真正难的不是改配置，是确认每个连接从哪来、用完是否归还、空闲多久该回收——日志里打连接ID、监控Threads_connected曲线、压测时抓PROCESSLIST快照，这三件事比调参重要得多。
