先查缓冲区、内存和连接释放问题，再调max_connections；确认mysql实际加载的配置文件路径，修改对应my.cnf中[mysqld]段；同步调整系统ulimit、php-fpm子进程数及wait_timeout参数。
别急着调 max_connections，连接数上不去，八成是缓冲区没配对、内存被吃光、或者连接根本没释放——先查清楚再动配置。
my.cnf 里 max_connections 改了却没生效？确认 MySQL 实际加载的是哪个文件
宝塔改完「配置修改」页面保存，重启 MySQL 后 SHOW VARIABLES LIKE 'max_connections'; 还是老值？大概率是配置没落到真正生效的文件里。MySQL 启动时只认第一个找到的有效配置，顺序固定：/etc/my.cnf → /etc/mysql/my.cnf → /www/server/mysql/etc/my.cnf → ~/.my.cnf。宝塔有时会把用户修改写进 /www/server/mysql/my.cnf，但实际加载的是 /etc/my.cnf。
- 执行
mysql --help | grep "Default options"看加载顺序 - 用
mysql -Nse "SELECT @@global.config_file"（MySQL 8.0+）或查错误日志grep "my.cnf" /www/server/data/*.err确认真实路径 - 直接编辑那个被读取的文件，在
[mysqld]段内加max_connections = 200，别加在段外或注释里 - 改完必须
systemctl restart mysqld，宝塔面板点「重启」也行，但不能只点「重载配置」
设高 max_connections 反而让 MySQL 直接挂掉？检查系统级文件描述符和内存硬限制
设成 500 后 MySQL 启动失败，日志里报 Can't create thread 或 Too many open files，说明 Linux 系统没给 mysqld 进程开够“能打开多少个连接”的权限，或者物理内存撑不住这么多连接线程。
- 执行
ulimit -n查当前限制，若 ≤ 1024，需在/etc/security/limits.conf末尾加两行：mysql soft nofile 65535和mysql hard nofile 65535 - 每个连接默认占 20–30MB 内存（取决于
sort_buffer_size等），512MB 小内存服务器别设超 300；2GB 内存建议 ≤ 150 -
innodb_buffer_pool_size别盲目拉高，它和max_connections共享内存池，2GB 总内存机器设innodb_buffer_pool_size = 800M+max_connections = 120已接近极限 - 改完
limits.conf必须重启mysqld进程，reload不生效
PHP-FPM 子进程数和 MySQL 连接数是隐性绑定关系
你调高了 max_connections，但 PHP 还是报 Too many connections？不是 MySQL 不给连，是 PHP-FPM 的 pm.max_children 设太高，每个子进程都建一个连接，100 个子进程就占满 100 个槽位，根本没留给定时任务、后台脚本或突发请求的空间。
- 查当前设置：
宝塔 → 网站 → PHP 设置 → 配置文件，找pm.max_children（默认常为 50） - 粗略换算：单请求平均建 1.2 个连接 ×
pm.max_children = 50→ 至少占 60 连接；再加 cron、队列、管理后台，151 很快见底 - 推荐上限：
pm.max_children ≤ max_connections × 0.6，比如max_connections = 200，那pm.max_children别超 120 - 开启动态伸缩：
pm = dynamic+pm.start_servers/pm.min_spare_servers，避免空闲连接长期占位
wait_timeout 不调，max_connections 再大也是摆设
连接数始终卡在 100 多，SHOW PROCESSLIST 一看全是 Sleep 状态、Time 值几千秒——这些连接早该被 MySQL 主动断开了，但默认 wait_timeout = 28800（8 小时），它们挂着不动，新请求只能排队等死。
- 宝塔数据库 → 点击对应库 → 「配置修改」，把
wait_timeout和interactive_timeout都设成300（5 分钟）或600（10 分钟） - 改完必须重启 MySQL，仅保存不重启无效
- 同时检查应用层：ThinkPHP 漏写
Db::close()、CI3 没触发$this->db->close()、PDO 没置$pdo = null，都会导致连接不释放 - 临时验证可运行
SET GLOBAL wait_timeout = 300;，观察 Sleep 连接是否快速下降
真正卡住连接数的，往往不是 max_connections 这个数字本身，而是它背后那一整套资源链：系统文件描述符、物理内存、PHP 子进程调度、应用层连接生命周期管理。任何一个环节没对齐，调再高的值也只是把崩溃时间往后推几个小时而已。
