MySQL 5.7 默认 max_connections 为151，偏保守设计，易触发“Too many connections”错误；需结合内存、文件描述符及open_files_limit动态或永久调整，并配合应用端连接池优化。
MySQL 5.7 默认 max_connections 是 151，对中等以上并发的应用来说确实不够用——不是“过小”，而是设计上偏保守；它在单机轻量场景下够用，但一旦业务流量上来，ERROR 1040: Too many connections 就会频繁出现。
为什么 151 在实际中容易不够用？
这个值是 MySQL 启动时根据可用内存自动推算的初始值（最低不低于 151），并非硬编码死值，但多数安装包和容器镜像都直接沿用该默认。关键问题在于：
- 每个连接平均消耗约 256KB–1MB 内存（取决于线程栈、临时表、排序缓冲区等），151 个连接就可能吃掉 100MB+ 内存，但现代服务器远不止这点资源，限制反而成了瓶颈
- 应用若未使用连接池（比如直连 + 短生命周期连接），很容易在秒级内创建数十甚至上百新连接，瞬间打满 151 上限
- 云数据库（如阿里云 RDS、腾讯云 CDB）虽允许调高，但默认仍设为 151 或略高，需手动干预
动态修改 max_connections 的前提与风险
执行 SET GLOBAL max_connections = 500 看似简单，但必须满足几个隐性条件：
- 当前用户需有
SUPER权限（普通 DBA 账号通常不够，root@localhost一般可以） - 操作系统层面的文件描述符限制不能卡住：运行
ulimit -n查看，若低于 1024，MySQL 即便设了 500 也可能无法真正建立那么多连接 - MySQL 自身的
open_files_limit必须 ≥max_connections，否则会静默失败或报错Can't create thread - 动态设置后，已存在的空闲连接不会释放，但新连接可立即使用新上限；注意：此操作不触发连接回收，也不会清理
sleep状态连接
如何安全地动态扩容并验证生效？
推荐按顺序执行以下操作，避免误判：
- 先查现状：
SHOW VARIABLES LIKE 'max_connections';和SHOW STATUS LIKE 'Threads_connected'; - 再确认系统水位：
SHOW GLOBAL STATUS LIKE 'Max_used_connections';—— 若长期接近 151，说明已到临界点 - 执行扩容：
SET GLOBAL max_connections = 500;（注意：不能写成SET max_connections = 500，漏掉GLOBAL无效） - 立刻验证：
SHOW VARIABLES LIKE 'max_connections';，必须看到返回值更新；同时检查SHOW VARIABLES LIKE 'open_files_limit';是否 ≥ 500 - 观察几分钟内是否仍有
ERROR 1040报错，以及Threads_connected是否能稳定升至 300+（取决于真实负载）
动态修改后最常被忽略的一件事
它只是“让 MySQL 允许更多连接进来”，但不会自动优化连接生命周期。如果应用端仍持续创建短连接、不复用、不主动 close()，那么即使扩到 1000，内存和文件描述符照样会被耗尽。真正的解法永远是两端配合：服务端调上限 + 应用端配连接池（如 HikariCP、Druid）+ 设置合理的 wait_timeout（建议 300–600 秒）。否则，你只是把“连接数爆了”延迟到了更晚一点的时间点。
