MySQL报错Too many connections的直接原因
遇到“Too many connections”报错，很多人的第一反应是SQL太慢或者内存不足。其实，真正的“元凶”很直接：当前活跃的数据库连接数，已经超过了MySQL配置文件里设定的max_connections上限。一旦触及这个硬性天花板，MySQL会直接拒绝新的连接请求，而不是让它们排队等待。
哪些情况容易触发这个错误呢？最常见的有两种：一是数据库参数wait_timeout或interactive_timeout设置得过大（比如默认的8小时），而应用程序没有使用连接池，每次处理请求都新建一个连接，用完又不主动关闭；二是应用端的连接池配置本身就不合理，其最大连接数设置得远高于MySQL服务端允许的上限。
查清谁在占着连接不放
面对这个错误，千万别急着去调大max_connections。先搞清楚，现有的连接到底被谁占用、为什么没有被释放，这才是治本的关键。
排查的第一步，是执行SHOW PROCESSLIST;命令。这里需要重点关注Command列显示为Sleep，且Time值很大的那些行——它们代表了那些处于空闲状态、但尚未被MySQL或应用端断开的连接。
如果想更精确地筛选，可以运行这条SQL：SELECT * FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 60;，它能帮你揪出空闲时间超过1分钟的所有连接。
最后，看一眼HOST列。如果显示的是类似127.0.0.1:xxxxx这种带端口号的格式，那基本可以断定是应用程序层（如Web服务）没有正确释放连接。如果显示的是localhost，则可能是本地的脚本或定时任务忘记关闭数据库连接了。
应用层必须启用连接池 + 合理设置参数
使用长连接本身不是问题，真正的问题是“连接建了不用、用了不放”。像PHP、Python、Ja va这些语言的MySQL客户端驱动，默认通常不提供连接池功能，这就需要我们借助框架或专门的中间件来补上。
具体到不同技术栈，可以这样操作：
- Python：如果用的是
pymysql，不要直接调用connect()。改用DBUtils.PooledDB，或者使用SQLAlchemy并配置create_engine(pool_size=5, max_overflow=10)。 - Node.js：使用
mysql2驱动时，必须显式传入connectionLimit: 10这样的参数来限制连接池大小，否则它默认会无限制地创建新连接。 - Ja va：如果使用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的快照——做好这三件事，远比盲目调参重要得多。
