mysql连接数受限主因是systemd的limitnofile限制，需同步修改my.cnf中max_connections、systemd服务文件中limitnofile及wait_timeout参数，并验证配置文件路径与语法有效性。
不是配置写错了，而是 MySQL 根本没读到、或读到了但被系统卡死了。 直接改 my.cnf 里的 max_connections 却看到值还是 214 或 4190，99% 是被 LimitNOFILE 拦住了——每个连接至少占 1 个文件描述符，而这个上限由 systemd 控制，不是配置文件说了算。
确认 MySQL 实际加载的是哪个配置文件
你改的 /etc/my.cnf 可能根本没被读。Ubuntu/Debian 默认优先读 /etc/mysql/mysql.conf.d/mysqld.cnf，CentOS 7+ 则可能走 /etc/my.cnf.d/server.cnf。登录 MySQL 执行：
SHOW VARIABLES LIKE 'config_file';
它会明确返回真实路径。接着检查该文件是否存在、是否在 [mysqld] 段内写了 max_connections；写在 [client] 或无 section 的位置完全无效。还可以用命令验证语法是否被识别：
mysqld --defaults-file=/path/to/my.cnf --verbose --help | grep "max_connections"
如果没输出，说明配置被跳过（常见于括号不闭合、等号多空格、引号未配对）。
systemd 的 LimitNOFILE 必须同步调大
MySQL 启动后进程受 systemd 服务单元限制，/etc/security/limits.conf 对 mysqld 服务进程基本无效。必须编辑对应 service 文件：
- 查路径：
systemctl cat mysqld或systemctl cat mysql（看实际服务名） - 编辑文件（如
/lib/systemd/system/mysqld.service），在[Service]段下添加：
LimitNOFILE=65535<br>LimitNPROC=65535
改完必须执行：systemctl daemon-reload（仅 restart 不够），再 systemctl restart mysqld。否则修改永不生效。
open_files_limit 是硬性天花板
MySQL 启动时会根据系统允许的文件描述符数自动推导 open_files_limit，而 max_connections 实际生效值 = min(配置值, open_files_limit - 预留数)。预留数通常 800 左右（日志、表缓存等）。所以即使 max_connections=10000，若 open_files_limit=1024，最终也只跑得动约 214 个连接。
检查方式：
- MySQL 内：
SHOW VARIABLES LIKE 'open_files_limit'; - 确认 systemd 的
LimitNOFILE是否 ≥ 你期望的max_connections+ 1000 - 避免在
my.cnf中显式设open_files_limit = 1024—— 这会直接锁死上限
别忘了 wait_timeout 才是连接堆积的真凶
很多“Too many connections”其实不是缺连接数，而是几百个 Sleep 连接挂着不释放。默认 wait_timeout=28800（8 小时），应用不主动 close，MySQL 就一直养着。此时调大 max_connections 只会让内存和线程竞争更糟。
优先做：
-
SHOW PROCESSLIST;筛出State = 'Sleep'且Time > 300的连接 - 在
[mysqld]段加：wait_timeout = 300和interactive_timeout = 300 - 重启后观察
Threads_connected是否明显回落
真正要调 max_connections，必须同时满足：systemd LimitNOFILE 足够、open_files_limit 足够、应用层连接池（如 HikariCP 的 maximumPoolSize）小于该值——漏掉任意一环，配置就只是纸面数字。
