max_connections需根据实测单连接内存、innodb_buffer_pool_size预留及os限制综合设定，避免oom；应先临时调优验证，再持久化配置，并同步调整wait_timeout以释放空闲连接。
别硬凑数字，max_connections 设高了反而容易触发 OOM 或 swap 颠簸，尤其在 8–16GB 内存的常见服务器上。 真实可用值取决于 innodb_buffer_pool_size 已占内存、系统预留、以及每个连接实际开销——不是用总内存除以 2MB 就能拍出来的。
查清当前连接真实内存占用，别信理论值
MySQL 每个连接的内存不是固定值，sort_buffer_size、read_rnd_buffer_size、tmp_table_size 等会话级参数都会叠加。空闲连接可能只占 1.5MB，但一个执行大排序的连接可能瞬间吃掉 20MB+。
- 先登录 MySQL 执行：
SHOW VARIABLES LIKE 'max_connections';和SHOW STATUS LIKE 'Threads_connected'; - 再在 Linux 终端跑：
ps aux --sort=-%mem | grep mysqld，看mysqld进程的 RSS 值 - 用 RSS ÷
Threads_connected得到当前平均单连接内存（比文档里“2–3MB”更准） - 如果结果明显高于 3MB，说明应用有慢查询或未关闭连接，得先优化 SQL 或连接池配置
扣掉 buffer pool 后再算 max_connections 上限
innodb_buffer_pool_size 是刚性内存大户，必须优先保障；它和连接数无关，但不预留够，连接数调再低也会卡住。
- 32GB 服务器，建议
innodb_buffer_pool_size = 20G（占 62%），留 4GB 给系统和其他进程 - 剩下约 8GB 可分配给连接：若实测单连接均值是 2.5MB，则理论天花板是
8 * 1024 / 2.5 ≈ 3200 - 但日常建议压到
500–1200，留足余量应对突发活跃连接 —— 因为Threads_running才是真正抢资源的 - 别忘了检查 OS 层限制：
ulimit -n，MySQL 实际能建的连接不能超过这个值
改配置必须分两步：临时验证 + 永久写入
直接改配置文件重启太重，先在线验证是否扛得住：
- 临时生效（重启失效）：
SET GLOBAL max_connections = 800; - 观察 1–2 小时：
SHOW STATUS LIKE 'Max_used_connections';是否接近新值，同时监控free -h和swap使用率 - 确认稳定后，再改配置文件（通常是
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf）的[mysqld]段落，加一行：max_connections = 800 - 最后执行：
sudo systemctl restart mysql（注意服务名可能是mariadb）
最常被忽略的一点：很多团队只盯着 max_connections，却没调 wait_timeout 和 interactive_timeout。默认 28800 秒（8 小时）会让空闲连接长期挂着，Threads_connected 慢慢堆满。生产环境建议设成 60–300 秒，配合应用层连接池的 idle timeout 使用。
