ALTER USER 是唯一立即生效的设置方式：MySQL 5.7 中限制用户并发连接数必须用 ALTER USER 'user'@'host' WITH MAX_USER_CONNECTIONS N，该操作即时生效、无需重启、不依赖 FLUSH PRIVILEGES。
ALTER USER 是唯一立即生效的设置方式
MySQL 5.7 中，限制特定用户并发连接数，ALTER USER 是唯一对已有用户**立即生效、无需重启、不依赖 FLUSH PRIVILEGES** 的方案。其他常见操作基本无效：SET GLOBAL max_user_connections = N 只影响后续新建用户的默认值，对已存在账号完全无感；GRANT ... WITH MAX_USER_CONNECTIONS 虽然语法合法，但仅在用户无权限时隐式创建（行为不可靠），且不推荐用于生产环境已有账号的修改。
正确写法必须带 WITH 关键字，且 User@Host 必须与 SHOW GRANTS FOR 'user'@'host' 输出的完全一致：
ALTER USER 'app_user'@'%' WITH MAX_USER_CONNECTIONS 8;ALTER USER 'report_user'@'localhost' WITH MAX_USER_CONNECTIONS 2;- 若用户是
'app_user'@'127.0.0.1'，写成'app_user'@'localhost'就是错的——MySQL 视为两个独立账号
验证是否真写入 mysql.user 表
命令执行成功 ≠ 配置已生效。MySQL 不会把 MAX_USER_CONNECTIONS 写进权限语句里，SHOW GRANTS 永远不会显示它。唯一可信路径是查系统表：
SELECT User, Host, max_user_connections FROM mysql.user WHERE User = 'app_user';
注意三点：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 字段名是全小写
max_user_connections，不是Max_user_connections或驼峰写法 - 返回值必须是具体数字（如
8），NULL、0或-1都等效于“不限制” - 普通用户默认无权查
mysql.user，需SELECT ON mysql.*权限，或用root登录验证
实测触发 ERROR 1226 才算真正起作用
配额写对了，不代表运行时能拦住连接。必须实测超限行为：
- 开多个终端，并发执行：
mysql -u app_user -p -e "SELECT 1;" - 设的是
MAX_USER_CONNECTIONS 5，第 6 次连接应明确报错：ERROR 1226 (42000): User 'app_user' has exceeded the 'max_user_connections' resource (current value: 5) - 该错误不是故障，而是限制生效的明确信号；MySQL 不会静默丢弃连接
- 已建立的连接不会被中断，只拒绝新连接——所以压测前先清理 idle 连接更易复现
连接池配置必须 ≤ 用户限制值
这是最常被忽略的落地环节。应用层用了 HikariCP、Druid 等连接池，如果池子大小超过数据库账号限制，启动或首次调用就会失败：
- HikariCP 的
maximumPoolSize必须 ≤ 对应账号的MAX_USER_CONNECTIONS - Druid 的
maxActive同理 - 哪怕业务流量为零，连接池默认维持 idle 连接，也会立刻占满配额
- 多个微服务共用同一账号（如
'app'@'%'）时，总连接数叠加突破限制——建议按服务或实例拆分账号，例如'app_web1'@'10.0.1.10'
限制只校验新建连接，且只统计非 Sleep 状态的活跃连接；wait_timeout 和 max_connections 完全不参与这个控制逻辑。配额生效后性能影响几乎为零，但连接池行为必须同步对齐，否则再准的配置也白搭。
