max_connections 应根据 Threads_connected 和 Threads_created 实时状态动态调整，起步值8GB内存设600，配合应用层连接池对齐；thread_cache_size 推荐16–64，以 Threads_created/Uptime < 0.1 为优；wait_timeout 必须≤300秒，避免假活连接。
max_connections 设置过低会导致连接拒绝，但盲目调高反而引发内存耗尽或线程竞争加剧——关键不是堆数量，而是让每个连接更轻、复用更稳、等待更短。
怎么设 max_connections 才不翻车？
直接看 Threads_connected 和 Threads_created 两个状态值，比拍脑袋估算靠谱得多：
- 如果 Threads_connected 长期接近你设的 max_connections，且 Threads_created 每秒增长 > 1，说明连接池没兜住，连接频繁新建；
- 如果 Threads_connected 峰值只有 200，却把 max_connections 设成 2000，innodb_buffer_pool_size 很可能被挤占，反而出现缓存命中率暴跌；
- 推荐起步值：8GB 内存服务器设为 600，再结合应用层连接池（如 HikariCP 的 maximumPoolSize）做对齐，避免数据库和应用各自维护一套连接生命周期。
thread_cache_size 不是越大越好
它的作用是复用空闲线程，省掉创建/销毁开销。但设太高会浪费内存，太低又导致频繁新建线程：
- 查看 Threads_created 变化率，如果每分钟新增 > 100，说明当前 thread_cache_size 不够；
- 生产环境常见有效值是 16–64，不是“越多越快”；
- 它和 max_connections 无固定比例关系，重点看 Threads_created / Uptime 的比值是否稳定在 0.1 以下；
- 注意：MySQL 8.0+ 默认不启用线程池插件（thread_pool.so），高并发下手动启用比单纯调大 thread_cache_size 更治本。
wait_timeout 必须缩到 300 秒以内
默认 28800 秒（8 小时）会让空闲连接长期占着资源，尤其在连接池配置不当或应用未正确 close 的场景下：
- 应用层连接池 idle timeout 若设为 600 秒，而 MySQL 的 wait_timeout 是 28800，大量连接会在池里“假活”，实际已断开；
- 推荐统一设为 300（5 分钟），并确保应用层 validationTimeout wait_timeout；
- 修改后观察 Aborted_clients 是否突增，若明显上升，说明有客户端没处理好连接异常，得修代码，不是调参能解决的。
innodb_buffer_pool_size 是高并发的底层杠杆
它不是“越大越好”的静态参数，而是要动态匹配真实工作集：
- 如果 innodb_buffer_pool_reads / innodb_buffer_pool_read_requests > 0.01（即缓存命中率
- 但设到物理内存的 80% 以上，可能挤压 OS 文件缓存或触发 swap，反而拖慢整体响应；
- 更稳妥的做法：先设为 60%，压测时监控 Innodb_buffer_pool_wait_free，非零就说明实例在等页清理，需调大或优化长事务；
- MySQL 8.0.12+ 支持在线调整，别怕试，但每次只调 ±1G，观察 10 分钟后再动下一次。
真正卡住高并发的，往往不是某个参数没调够，而是多个参数之间互相打架——比如 max_connections 拉高了，innodb_buffer_pool_size 没跟上，结果所有连接都在抢内存，锁等待飙升。调参得像调音，一个旋钮动了，其他几个得同步微调。
