合理值需结合Max_used_connections历史峰值、应用连接池规模及内存估算，推荐起步设400并同步调低wait_timeout；必须写入my.cnf重启生效，且ulimit -n须≥max_connections+200。
max_connections 设多少才算合理
别直接写 1000 或 65535——这大概率会触发 OOM killer 杀掉 mysqld 进程。真实值取决于你每连接实际占多少内存，而它不是固定值：sort_buffer_size、read_buffer_size 等线程级变量一调大，单连接可能从 256KB 涨到几 MB。
实操建议：
- 先查历史峰值：
SHOW STATUS LIKE 'Max_used_connections';，再结合应用侧连接池配置（如 HikariCP 的maximumPoolSize× 实例数）加 30% 余量 - 内存兜底估算：假设每连接平均占 4MB，16GB 内存服务器理论硬上限约 4000，但线上建议起步设
max_connections = 400 - 必须同步检查系统限制：
ulimit -n要 ≥max_connections + 200（留够日志、表缓存等文件描述符），否则 MySQL 启动失败或运行中崩溃 - 改完别只靠
SET GLOBAL max_connections = 400——某些版本重启后会回退，必须写进my.cnf的[mysqld]段并重启
thread_pool_size 在社区版根本用不了
MySQL 社区版（5.7/8.0）原生不支持 thread_pool 插件。你搜到的 INSTALL PLUGIN thread_pool SONAME 'thread_pool.so' 在社区版执行只会报错 Unknown plugin 'thread_pool'。
常见误操作和替代方案：
- 别在社区版硬配
thread_handling = pool-of-threads或thread_pool_size—— 配置会被忽略，启动日志里有警告但容易被漏看 - 真正能用的轻量级替代是
thread_cache_size：它缓存空闲线程供新连接复用，推荐值为ceil(max_connections / 16)，但一般不超过 16（设太大反而增加管理开销） - 如果真需要线程池，必须换 Percona Server 或 MySQL Enterprise，并确认插件已加载：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'thread_pool';
wait_timeout 和 interactive_timeout 是连接泄漏放大器
这两个参数默认 28800 秒（8 小时），在应用连接未正确关闭时，会让“假死连接”长期占着 max_connections 名额，最终导致 ERROR 1040 (08004): Too many connections。
关键动作：
- 把
wait_timeout和interactive_timeout都设成 300–1800（5–30 分钟），强制空闲连接快速释放 - 上线前务必跑一次泄漏检测：
SELECT ID, USER, HOST, DB, COMMAND, TIME FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 600;，TIME > 600 且持续存在，基本就是应用没 close() - 配合监控
Threads_connected曲线：如果它缓慢爬升不回落，比突然爆满更危险——说明泄漏正在发生，只是还没到阈值
连接池大小和 thread_cache_size 要联动看
应用层连接池（如 HikariCP）和 MySQL 的 thread_cache_size 不是独立调优项，它们共同决定线程创建开销是否可控。
判断依据看这两个状态值：
-
Threads_created持续上涨 → 说明新连接总得新建线程，thread_cache_size太小或应用连接池波动太大 -
Threads_connected长期远低于max_connections，但Threads_created仍高 → 应用连接池配置不合理（比如最小空闲数太低，频繁缩容扩容） - 典型搭配：HikariCP
maximumPoolSize = 20× 4 台服务 = 80，thread_cache_size设 8 就够；若设到 32，反而可能因缓存淘汰策略引入额外延迟
最常被忽略的一点：线程池优化不是堆参数，而是盯住 Threads_created 是否稳定、Threads_connected 是否有规律波动、以及应用日志里有没有 connection timeout 或 abandon warning——这些信号比任何理论公式都准。
