MySQL并发连接上限由max_connections变量控制,可通过SHOW VARIABLES LIKE 'max_connections'查看;其值可来自配置文件、启动参数或动态设置,但需注意资源限制与生效条件。

查看当前最大连接数设置
MySQL 实际允许的并发连接上限,由 max_connections 系统变量控制。它不是看 SHOW PROCESSLIST 返回了多少行,而是看这个变量值——哪怕当前只连了 5 个客户端,只要设成了 100,上限就是 100。
查法很简单:
SHOW VARIABLES LIKE 'max_connections';
注意:这个值可能来自配置文件(my.cnf 或 my.ini),也可能被启动时用 --max_connections=200 覆盖,还可能被运行时动态修改过(但重启后失效)。
- 如果返回的是默认值(如 151),大概率没在配置里显式设置
- 如果值异常小(比如 20),先检查是不是被运维脚本或容器启动参数硬编码了
- 云数据库(如阿里云 RDS、腾讯云 CDB)通常限制更严,且部分不支持动态改,得走控制台或工单
修改 max_connections 的三种方式及适用场景
改这个值不是“越大越好”,也不是“改了立刻生效”——得看你怎么改、在哪改、改完有没有资源兜底。
静态配置(推荐长期使用):
[mysqld] max_connections = 500
写在 /etc/my.cnf 或 /usr/my.cnf 的 [mysqld] 段下,改完必须重启 MySQL 才生效。适合稳定环境,避免意外漂移。
动态设置(临时应急):
SET GLOBAL max_connections = 600;
立即生效,但仅维持到下次重启。常用于排查连接耗尽问题时“先顶住”,但别依赖它做长期方案——万一服务挂了再起来,又回默认值,问题重现。
- 执行前确认你有
SUPER权限(普通应用账号不行) - Linux 下如果报
ERROR 1238 (HY000): Variable 'max_connections' is a read only variable,说明启用了--skip-grant-tables或配置了read_only=ON - 某些低配机器(比如 1G 内存)设太高会导致
Cannot allocate memory错误,因为每个连接至少占几 MB 内存
连接数打满的典型现象和误判点
应用报 “Too many connections” 不一定真是 max_connections 到了极限——也可能是连接泄漏、认证失败堆积、或连接池配置反模式。
先别急着调大数值,跑这三条命令快速定位:
SHOW STATUS LIKE 'Threads_connected';
SHOW STATUS LIKE 'Threads_running';
SELECT user, host, db, command, time FROM information_schema.PROCESSLIST WHERE time > 60;
-
Threads_connected接近max_connections?真满了 -
Threads_running却很低(比如 - PROCESSLIST 里一堆
Sleep状态且time超长,基本可断定是应用端连接未释放 - 如果看到一堆
Connect状态卡在Authentication阶段,可能是密码错误重试或 DNS 解析慢,不是连接数不够
调整后必须验证的两个关键点
改完 max_connections,光看 SHOW VARIABLES 返回新值没用——得确认 OS 层资源跟得上,且应用真能建这么多连接。
Linux 对每个进程的文件描述符有限制(MySQL 每个连接 ≈ 1 个 socket fd),所以必须同步调高:
ulimit -n
如果返回 1024,而你设了 max_connections = 2000,MySQL 启动时会默默截断到 1024,日志里可能只有一句 Changed limits: max_open_files: 1024,容易忽略。
- 永久生效要改
/etc/security/limits.conf,加两行:mysql soft nofile 65535mysql hard nofile 65535 - systemd 管理的服务还要额外改
/etc/systemd/system/mysqld.service.d/override.conf,加LimitNOFILE=65535 - 应用侧连接池(如 HikariCP 的
maximumPoolSize)如果设得比max_connections还大,等于主动制造排队,反而放大延迟
内存和文件描述符这两块,比改一个数字难 debug 得多,但出问题时往往最先崩在这儿。


















