mysql的max_connections实际生效值受配置文件路径、systemd limits、open_files_limit及ulimit -u四重限制，需逐层排查：先确认show variables like 'config_file'读取的配置文件及[mysqld]段设置，再检查systemd服务单元的limitnofile/limitnproc，确保open_files_limit足够大且未被显式设小，最后验证ulimit -u是否满足需求。
不是配置写错了，而是配置根本没被 MySQL 读到，或者读到了但被系统级限制拦在了门外。
确认 MySQL 实际加载的配置文件路径
MySQL 启动时可能压根没读你改的那个 my.cnf。比如你改了 /etc/my.cnf，但它实际用的是 /etc/mysql/mysql.conf.d/mysqld.cnf（Ubuntu/Debian 系统默认优先级更高）；又或者启动时指定了 --defaults-file，直接绕过了所有默认路径。
- 登录 MySQL 执行：
SHOW VARIABLES LIKE 'config_file';—— 这会明确告诉你它读的是哪个文件 - 检查该文件是否存在、是否在
[mysqld]段内写了max_connections；写在[client]或文件开头无 section 的地方完全无效 - 用
mysqld --defaults-file=/path/to/my.cnf --verbose --help | grep "max_connections"测试配置能否被解析，有语法错误（比如漏括号、等号多一个、引号不闭合）会导致整个文件静默跳过
systemd 环境下 limits.conf 不生效是常态
Ubuntu 16.04+、CentOS 7+ 全面转向 systemd 后，/etc/security/limits.conf 对 service 进程已基本失效——它只影响交互式登录会话，而 mysqld 是由 systemd 拉起的独立服务进程。
- 必须修改 service 单元文件：编辑
/lib/systemd/system/mysql.service或/usr/lib/systemd/system/mysqld.service - 在
[Service]段下添加：LimitNOFILE=65535和LimitNPROC=65535 - 改完务必执行：
systemctl daemon-reload && systemctl restart mysql（仅restart不够，daemon-reload才能重载 limit 配置）
open_files_limit 卡死 max_connections 上限
MySQL 每个连接至少占用 1 个文件描述符，而 max_connections 实际生效值 = min(配置值, open_files_limit - 预留线程数)。如果 open_files_limit 只有 1024，那 max_connections 再设 10000 也顶多跑到 214 左右（预留约 800 给日志、表缓存等）。
- 查当前值：
SHOW VARIABLES LIKE 'open_files_limit'; - 查系统级 ulimit：
ulimit -n（注意：这是 shell 会话的值，不代表 mysqld 进程看到的值） - 真正起作用的是 systemd 的
LimitNOFILE，不是limits.conf；同时要确保open_files_limit在 MySQL 配置中未被显式设为过小值（如open_files_limit = 1024）
云数据库 RDS/Aurora 修改方式完全不同
阿里云 RDS、AWS Aurora 这类托管服务，SET GLOBAL max_connections 基本无效，配置文件根本不可写，连 mysql.service 都不存在。
- 必须进控制台找「参数组」，修改
max_connections参数项 - 修改后需「重启实例」或「应用参数组」（部分参数要求重启才生效）
- 注意不同规格实例有硬上限，比如 2 核 4G 的 RDS 最高只允许设到 3000，超了也白设
最容易被忽略的一点：即使所有配置都对了，max_connections 生效还依赖 ulimit -u（最大用户进程数）。如果它卡在 500，而你设了 5000 连接，MySQL 启动时就会默默把 max_connections 往下调到安全值——这个过程不会报错，只会静默妥协。
