MySQL的max_connections合理值通常为300–500，需结合内存（如16GB约支持4000上限）、并发模式及连接内存占用动态调整，超500–800应优先优化应用层连接复用或读写分离。
max_connections 设置多少才合理
MySQL 默认的 max_connections 通常是 151，但这个值既不是越高越好，也不是越低越安全。实际取值取决于你的物理内存、并发查询模式和每个连接平均内存占用。
一个连接在空闲时约占用 256KB 内存，执行复杂查询时可能飙升到几 MB。如果服务器有 16GB 内存，保守按每连接 4MB 算，硬上限约 4000 连接；但真实场景中，超过 500–800 通常意味着连接管理已成瓶颈，该考虑应用层连接复用或读写分离了。
- 线上建议从
300–500起步，配合监控Threads_connected和Threads_running动态调整 - 避免设为
10000这类整数——它不会提升性能，反而容易触发 OOM killer 杀掉 mysqld - 修改后必须重启或执行
SET GLOBAL max_connections = 400（后者在某些版本中重启失效）
thread_pool_size 不是万能开关
MySQL 官方企业版和 Percona Server 支持线程池插件（thread_pool），但社区版原生不带。它本质是用固定数量的工作线程轮询处理大量连接请求，缓解高并发下线程创建/销毁开销。
但它对长事务、锁等待敏感，且无法绕过 max_connections 限制。启用前务必确认你用的是支持版本（如 Percona Server 8.0+ 或 MySQL Enterprise）。
- 启用方式：加载插件
INSTALL PLUGIN thread_pool SONAME 'thread_pool.so'，再设thread_pool_size = CPU核心数（通常 4–16） - 不要盲目设大——
thread_pool_size > CPU核心数 * 2反而引发上下文切换抖动 - 观察
SHOW STATUS LIKE 'Thread_pool%'中的Thread_pool_idle_threads和Thread_pool_waited，后者持续非零说明池子太小
wait_timeout 和 interactive_timeout 容易被忽略
这两个参数控制空闲连接存活时间，默认 28800 秒（8 小时）。在连接池复用不规范的应用里，大量“假死连接”会占满 max_connections，导致新请求被拒。
它们的区别在于：wait_timeout 作用于普通连接，interactive_timeout 仅影响设置了 CLIENT_INTERACTIVE 标志的连接（如 mysql 命令行客户端）。
- 生产环境建议统一调低至
300（5 分钟）或600（10 分钟） - 应用端必须正确调用
connection.close()或使用连接池的 validateQuery，否则超时只是延缓问题爆发 - 注意 JDBC URL 中的
autoReconnect=true已废弃，且无法解决超时断连后的事务状态丢失
真正卡住性能的往往是 connection 持有者
调大 max_connections 或加线程池，解决不了应用端连接泄漏、长事务不提交、慢查询阻塞等问题。MySQL 的连接数压测结果，90% 以上反映的是业务逻辑缺陷而非配置不足。
先查 SHOW PROCESSLIST，重点关注 State 列：长时间显示 Sending data、Locked、Copying to tmp table 的线程，比盯着 Threads_connected 数字更有价值。
- 用
SELECT * FROM performance_schema.threads WHERE TYPE = 'FOREGROUND'查活跃线程详情 - 开启慢日志（
slow_query_log = ON+long_query_time = 1）定位拖慢整体响应的查询 - 连接池配置（如 HikariCP 的
maximumPoolSize）必须和 MySQL 的max_connections协同，别让 10 个服务各自配 200 连接，合计冲到 2000
