max_connections不是设得越高越好，需结合内存、并发和连接池综合配置；查当前值用SHOW VARIABLES LIKE 'max_connections'，查历史峰值用SHOW GLOBAL STATUS LIKE 'Max_used_connections'，理想比值约0.85。
直接说结论：max_connections 不是设得越高越好，设错位置、不配系统限制、不看内存占用，改了也白改。
怎么查当前 max_connections 和实际用过多少
连进 MySQL 后执行两条命令就能摸清底子：
-
SHOW VARIABLES LIKE 'max_connections';—— 看当前生效的上限值 -
SHOW GLOBAL STATUS LIKE 'Max_used_connections';—— 看历史上同时连上来最多有多少个
这两个数一比，就知道配置合不合适。理想比例是 Max_used_connections / max_connections ≈ 0.85。如果长期只有 10%～20%，说明设太高了，白占内存；如果经常打到 95% 甚至报 ERROR 1040: Too many connections，就得调高。
临时改 vs 永久改，改哪儿才真生效
临时改只救急，命令是：
-
SET GLOBAL max_connections = 1000;—— 当前进程立刻生效，但 MySQL 一重启就回滚
永久生效必须改配置文件：
- Linux 下通常是
/etc/my.cnf或/etc/mysql/my.cnf - Windows 下是
C:\ProgramData\MySQL\MySQL Server X.X\my.ini - 在
[mysqld]段下加一行：max_connections = 1000
改完必须重启服务：systemctl restart mysqld（Linux）或 net stop mysql && net start mysql（Windows）。别指望靠 SET GLOBAL 一劳永逸，它只是“热修复”，不是配置落地。
为什么改了配置还是显示 214 或其他小数值
常见于 systemd 管理的 MySQL（如 CentOS 7+/Ubuntu 16.04+）或 MariaDB。即使 my.cnf 写对了，系统级资源限制（比如打开文件数）卡着，MySQL 启动时会默默把 max_connections 往下调。
- 典型表现：
max_connections = 1000配了，SHOW VARIABLES却只显示 214 - 检查 systemd 服务限制：
/usr/lib/systemd/system/mysqld.service或mariadb.service - 在
[Service]下加两行：LimitNOFILE=10000和LimitNPROC=10000 - 改完运行：
systemctl --system daemon-reload，再systemctl restart mysqld - 验证是否生效：
cat /proc/$(pgrep mysqld)/limits | grep "Max open files"，确保 soft limit ≥ 10000
另外注意：max_connections 硬上限是 16384，设成 20000 也没用，MySQL 自动截断为 16384。
设多大才算合理：内存、并发、连接池要一起算
每个连接至少占 256KB～1MB 内存（取决于 buffer 设置），1000 个连接轻松吃掉 500MB+。更关键的是，并发连接多 ≠ 查询快——真正决定吞吐的是 Threads_running（当前正在执行的线程数），它通常远小于总连接数。
- 估算公式参考：
max_connections ≈ 可用内存(GB) * 1000 / 0.2（例如 16GB 内存服务器，建议设为 800–1000） - 上限不能超过操作系统
ulimit -n的 80% - 应用侧连接池（如 Spring Boot 的
max-active、Druid 的maxActive）要跟这个值匹配，否则池子开太大，后端扛不住；开太小，又浪费连接能力
最容易被忽略的一点：MySQL 允许 max_connections + 1 个连接，那额外一个专留给有 CONNECTION_ADMIN 权限的管理员账号——所以别把所有连接都配满，得留一个口子给紧急排障用。
