max_connections 设置多少才合理
MySQL 默认的
max_connections通常是 151，但这个值对生产环境几乎总是不够，尤其在 Web 应用并发请求多、连接未及时释放时，很快会报错
Too many connections。关键不是盲目调高，而是结合实际负载和资源评估。
实操建议：
先查当前峰值连接数：SHOW STATUS LIKE 'Threads_connected';，配合监控（如
Threads_running）观察 15 分钟以上波动 预估应用连接池大小 × 实例数（例如：应用侧 HikariCP
maximumPoolSize=20× 4 台服务 = 理论上限 80），再留 30% 余量 Linux 下注意系统级限制：
ulimit -n必须 ≥
max_connections+ 文件描述符开销（日志、表缓存等），否则 MySQL 启动失败或运行中崩溃 设太高反而有害：每个连接至少占用 256KB–2MB 内存（取决于
sort_buffer_size等线程变量），可能触发 OOM
thread_pool_size 不是万能开关
MySQL 官方企业版和 Percona Server 支持
thread_pool_size（线程池插件），它把大量客户端连接复用到少量工作线程上，缓解高并发下线程创建销毁开销。但社区版 MySQL（8.0/5.7）原生不支持——这点常被误读。
常见误区与替代方案：
试图在社区版启用thread_pool插件 → 报错
Unknown plugin 'thread_pool'，因为该插件仅限商业版本或 Percona 真正可用的轻量级替代是调整
thread_cache_size：它缓存空闲线程供新连接复用，推荐设为
ceil( (max_connections / 16) )，但上限一般不超过 16（过高反而增加管理开销） 如果确实需要线程池，必须换 Percona Server 或 MySQL Enterprise，并确认已加载插件：
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so';
thread_pool_size值并非越大越好：设为 CPU 核心数（或核数 × 2）较稳妥；设成 64 在 4 核机器上会导致严重争抢
连接泄漏比连接数不足更危险
很多“连不上”的问题根源不是
max_connections太小，而是应用端未正确关闭连接（比如没
close()、没走连接池回收流程、异常路径漏处理）。这类泄漏会让连接数缓慢爬升，最终卡死。
快速定位方法：
查长连接：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE FROM information_schema.PROCESSLIST WHERE TIME > 60;看空闲连接是否堆积：
SHOW STATUS LIKE 'Threads_connected';持续高于平均值且
Threads_running很低，大概率是泄漏 开启慢查询日志 + general_log（临时）可追踪连接生命周期，但注意 general_log 影响性能，勿长期开启 应用侧检查连接获取/释放是否成对：Spring Boot 的
@Transactional默认不自动 close，需确保 DataSource 配置了
removeAbandonedOnBorrow=true（旧版）或
removeAbandonedOnMaintenance=true（HikariCP）
连接相关参数要协同调优
max_connections单独调高没用，必须同步审视依赖它的其他参数，否则可能引发隐性故障。
关键联动项：
table_open_cache：应 ≥
max_connections × 2（每个连接可能打开多张表），否则频繁打开/关闭表导致性能抖动
open_files_limit：MySQL 启动时取
ulimit -n和配置值的较小者；若设了
max_connections=2000，但
open_files_limit=1024，MySQL 会静默截断连接数
wait_timeout/
interactive_timeout：避免空闲连接长期占位，建议设为 300–600 秒（5–10 分钟），太短会导致应用重连风暴
max_connect_errors：默认 100，若因连接泄漏导致大量失败登录，可能触发主机被锁，建议调大至 1000 并配合监控告警
真正难的不是改几个数字，而是把连接从“应用怎么拿、怎么还”到“MySQL 怎么管、怎么放”串成一条可验证的链路。多数线上事故，出在中间某环被当成黑盒跳过了。
