max_connections需根据实际内存和并发需求合理设置，非越大越好；建议32GB服务器设为500–1200，配合wait_timeout=60–300秒、interactive_timeout=28800秒，并通过SHOW PROCESSLIST定位异常连接。
max_connections 设置多少才不爆内存
MySQL 的 max_connections 不是越大越好，每个连接会占用约 2–3MB 内存（含线程栈、连接缓冲区、临时表等），超配会导致 OOM 或频繁 swap。真实可用值取决于「空闲连接实际开销」和「峰值并发活跃度」，不是简单用总内存除以单连接开销。
- 先查当前实际内存占用：
SHOW VARIABLES LIKE 'max_connections';+SHOW STATUS LIKE 'Threads_connected'; - 用
ps aux --sort=-%mem | grep mysqld看 mysqld 进程 RSS，再除以Threads_connected值，估算单连接平均内存（比理论值更准） - 预留至少 30% 内存给系统、buffer pool、其他进程；buffer_pool_size 通常占物理内存 50–75%，这部分和连接数无关但必须先扣掉
- 例如：32GB 服务器，设
innodb_buffer_pool_size = 20G，系统+其他留 4G，则剩约 8G 可分配给连接 —— 按均值 2.5MB/连接算，上限约 3200，但日常建议压到 500–1200 之间，留足余量
wait_timeout 和 interactive_timeout 到底该设多长
这两个参数控制空闲连接自动断开时间，直接影响连接池复用率和 max_connections 实际压力。设太短，应用层频繁重连；设太长，大量“假在线”连接卡着名额不释放。
-
wait_timeout适用于普通连接（如 PHP-FPM、Java JDBC 非交互式），建议 60–300 秒（5 分钟足够覆盖多数 HTTP 请求生命周期） -
interactive_timeout仅影响带CLIENT_INTERACTIVE标志的连接（如 mysql CLI），可设为 28800（8 小时），不影响线上服务 - 注意：应用连接池（如 HikariCP、Druid）的
idleTimeout必须 ≤ MySQL 的wait_timeout，否则池内连接会被 MySQL 主动 kill，日志里出现Lost connection to MySQL server during query - 验证是否生效：
SHOW VARIABLES LIKE '%timeout%';，再用SHOW PROCESSLIST;观察 Sleep 状态连接的 Time 列是否在递增并最终消失
连接数被打满后，怎么快速定位是哪类连接在占坑
当 Threads_connected 接近 max_connections，不能只看总数，要区分“真业务请求”和“滞留垃圾连接”。盲目调高 max_connections 只是掩盖问题。
- 执行
SHOW PROCESSLIST;，重点关注Command列：大量Sleep且Time> 300 的，大概率是应用未正确 close 或连接池配置不当 -
State列出现Waiting for table metadata lock或Locked，说明有长事务或 DDL 卡住，得先 kill 对应线程（KILL [id];） - 用
SELECT * FROM information_schema.PROCESSLIST WHERE TIME > 60 AND COMMAND = 'Sleep';找出异常长睡连接，结合USER和HOST定位来源服务 - 如果全是同一
USER（如 app_rw），但HOST是内网 IP 池，大概率是某台应用节点连接泄漏，不是数据库本身容量问题
云数据库（RDS/Aurora）的连接数限制怎么破
阿里云 RDS、AWS Aurora 等默认 max_connections 是按规格硬编码的（如 4C8G RDS 最高 4000），你改不了全局变量，也不能直接 kill 系统线程。这时候拼的是“连接管理策略”而非参数调优。
- 必须启用连接池：PHP 用 PDO::ATTR_PERSISTENT，Java 用 HikariCP 并设
maximumPoolSize≤ RDS 规格允许值的 70% - 禁止应用代码中出现
mysql_connect()/new mysqli()后不 close；尤其注意异常分支里的漏关 - RDS 控制台的“实时性能”页能看
Active Sessions和Idle Sessions曲线，比SHOW PROCESSLIST更直观反映连接健康度 - 如果已触发“Too many connections”，且无法登录，RDS 提供“重启实例”按钮（慎用）或提工单让平台侧临时提升限额（仅应急）
真正难的从来不是算出那个数字，而是确认每一条连接背后有没有对应的业务请求、有没有被及时回收、有没有在锁等待里无声卡死 —— 参数只是标尺，连接状态才是真相。
