执行show variables like 'max_connections'查上限，show global status like 'Max_used_connections'查历史最高并发，二者比值理想为0.85；临时修改用set global，永久修改需改配置文件并重启服务。
怎么查当前最大连接数和实际用过多少
直接连进 MySQL，执行这两条命令就能摸清底子：show variables like 'max_connections'; 看上限；show global status like 'Max_used_connections'; 看历史上真正同时用过的最高值。这两个数一比，就知道配置合不合适——理想比例是 Max_used_connections / max_connections ≈ 0.85（即 85% 左右）。如果长期只有 10%～20%，说明 max_connections 设太高了，白占内存；如果经常打到 95% 甚至报 ERROR 1040: Too many connections，就得调高。
临时改和永久改，差别在哪
临时改只救急，命令是：set global max_connections = 1000;。但它只在当前 MySQL 进程里有效，重启就回滚。永久生效必须改配置文件：/etc/my.cnf（Linux）或 my.ini（Windows），在 [mysqld] 段下加一行：max_connections = 1000。改完一定得重启 MySQL 服务，否则不生效。
- 别指望靠
set global一劳永逸，它只是“热修复”，不是配置落地 - 配置文件位置常被搞错：MySQL 8.0+ 默认不带
my.cnf，得自己建；MariaDB 可能在/etc/mysql/mariadb.cnf或通过mysqld --help --verbose | grep "Default options"查找 -
max_connections的硬上限是 16384，设成 20000 也没用，MySQL 自动截断为 16384
为什么改了配置还是没生效
常见于 MariaDB 或 systemd 管理的 MySQL（比如 CentOS 7+/Ubuntu 16.04+）。即使 my.cnf 写对了，系统级资源限制（如打开文件数）卡着，MySQL 启动时会默默把 max_connections 往下调。典型表现是：你设了 1000，show variables 却只显示 214。
- 检查 systemd 服务限制：
/usr/lib/systemd/system/mariadb.service或mysqld.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
连接数不是越大越好，内存和并发有隐性成本
每个连接至少占用 256KB～1MB 内存（取决于 buffer 设置），1000 个连接轻松吃掉 500MB+。更关键的是，并发连接多 ≠ 查询快——真正决定吞吐的是 Threads_running（当前正在执行的线程数），它通常远小于总连接数。
- 连接池配置要匹配：应用侧（如 Spring Boot 的
max-active、Druid 的maxActive）建议设为2 × CPU核心数，别盲目堆到 1000 -
max_connections超过 500 后，性能提升边际递减，但 OOM 风险明显上升 - 如果频繁出现
Aborted_connects上升，优先查网络超时、DNS 解析失败或客户端未正确 close，而不是加连接数
最常被忽略的一点：改完配置后，一定要用 show global status like 'Threads_created'; 对比重启前后的增量——如果这个值飙升，说明连接复用率低，问题可能出在应用没用连接池，或者 pool 配置不合理。这时候调 max_connections 是治标不治本。
