MySQL连接数限制：全局与用户级控制的深度解析

在数据库运维中，连接数管理是个既基础又关键的话题。设置不当，轻则应用报错，重则服务雪崩。今天，我们就来把MySQL里关于连接限制的两个核心参数——max_connections和MAX_USER_CONNECTIONS——彻底讲清楚。

max_connections：全局总闸门，动态设置与持久化之别

首先明确一个概念：max_connections是服务级别的全局上限。它管的是整个MySQL实例能同时接纳多少TCP连接，是所有用户连接数的总和，而不是针对单个用户的配额。

修改这个参数，有两种路径，效果截然不同：

• 动态生效：通过执行 SET GLOBAL max_connections = 200; 可以立即调整。这非常方便，但有个“记忆短板”——一旦MySQL服务重启，这个设置就会丢失，恢复为配置文件里的值。
• 持久化生效：要想“一劳永逸”，就得修改配置文件（通常是my.cnf），在[mysqld]段落里加上一行max_connections = 200。不过，这种方式必须重启MySQL服务才能生效。

这里有个细节值得注意：动态设置时，如果当前的活跃连接数已经非常接近旧的上限，执行SET GLOBAL命令可能会被拒绝，并抛出ERROR 1227 (42501): Access denied。要成功执行，操作者必须具备SUPER或SYSTEM_VARIABLES_ADMIN权限。

精细化管控：用MAX_USER_CONNECTIONS实现用户级资源隔离

如果只想限制某个特定用户的并发连接数，该怎么办？MySQL本身并没有一个全局开关来统一设置所有用户的连接上限，但它提供了一个更精细化的工具：在用户级别进行硬编码限制。

这通过CREATE USER或ALTER USER语句中的MAX_USER_CONNECTIONS选项来实现，本质上是一种基于权限系统的资源隔离方案。

具体操作要点如下：

• 创建用户时指定：CREATE USER 'app_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_USER_CONNECTIONS 10;
• 修改已有用户：ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 10;
• 参数含义：设置为0表示不限制（这也是默认值），只有设为正整数时，限制才会真正启用。
• 计数维度：这个限制是以“用户+主机”的组合为独立单位进行计数的。也就是说，'user'@'192.168.%'和'user'@'localhost'会被视为两个不同的账号，各自拥有独立的连接配额。
• 超限后果：当用户的连接数超过其配额时，尝试建立新连接会收到明确的错误：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 10)。

连接占用的陷阱：配额不会自动释放

理解MAX_USER_CONNECTIONS的关键在于，它限制的是“同时存在的活跃连接数”，而不是“每秒允许的连接请求数”。这意味着，如果一个连接建立后没有被正确关闭，它就会一直占用配额，直到被释放。

实践中，以下几个陷阱非常常见：

• PHP应用：使用已废弃的mysql_connect()或PDO时，如果默认不启用持久连接，且脚本结束后没有显式地断开连接（如unset($pdo)或$pdo = null），就可能快速创建大量连接并占满配额。
• Ja va连接池：使用HikariCP等连接池时，如果配置的maximumPoolSize大于数据库用户的MAX_USER_CONNECTIONS
• 僵尸连接：MySQL的wait_timeout参数（默认28800秒，即8小时）决定了空闲连接多久后被服务器主动断开。如果这个值设置过大，大量空闲连接会像僵尸一样长期挂起，导致活跃用户反而无法连接。
• 如何查看：要监控当前各用户的真实连接数，可以查询：SELECT user, host, COUNT(*) FROM information_schema.processlist GROUP BY user, host;