mysql 5.7+ 通过 create user 或 alter user 设置 max_queries_per_hour 实现用户级每小时查询上限，仅对普通用户生效，限制范围为非管理类语句总数，修改后需 flush privileges（8.0.12+ 自动刷新），且按连接独立滑动窗口计时。
MySQL 5.7+ 用户资源限制怎么配？
MySQL 原生支持通过 CREATE USER 或 ALTER USER 设置每小时查询上限，但必须启用 max_questions 资源限制，且仅对普通用户（非 root 或拥有 CONNECTION_ADMIN 权限的用户）生效。
实操时注意：该限制是「每小时累计执行的语句总数」，包括 SELECT、INSERT、UPDATE、DELETE 等所有非管理类语句；不计 SHOW、SET、USE 等元数据操作。
- 创建新用户并设限：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd123' WITH MAX_QUERIES_PER_HOUR 1000;
- 修改已有用户：
ALTER USER 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 500;
- 查看当前用户的资源限制：
SELECT user, host, max_questions FROM mysql.user WHERE user = 'api_user';
为什么 SET GLOBAL max_questions=... 不起作用？
max_questions 是用户级属性，不是全局变量，所以 SET GLOBAL max_questions = 1000 会报错 ERROR 1193 (HY000): Unknown system variable 'max_questions' —— 它根本不存在于系统变量列表中。
常见误解是把它当成类似 wait_timeout 的动态参数。实际它只在用户定义时固化存储在 mysql.user 表里，每次连接认证时加载，运行时不检查变更。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
- 修改后必须执行
FLUSH PRIVILEGES才能让新限制对后续连接生效（MySQL 8.0.12+ 在ALTER USER后自动刷新，但低版本仍需手动） - 已建立的活跃连接不受新限制影响，只对新建连接生效
- 如果用户有
GRANT OPTION或高权限，可能绕过限制（例如用代理账号切换上下文）
遇到 “User has exceeded the 'max_questions' resource” 怎么查？
错误信息是 ER_USER_LIMIT_REACHED，典型提示为：User 'api_user'@'10.0.1.5' has exceeded the 'max_questions' resource (current value: 1000)。
这个错误不会写入 error log，默认也不记录到 general_log，排查依赖主动监控或应用层日志捕获。
- 确认是否真超限：查
information_schema.PROCESSLIST只能看到当前连接，不能回溯历史查询数；唯一可靠方式是查mysql.user表里的max_questions值，并结合应用日志估算调用量 - 临时放行：用管理员账号执行
ALTER USER 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 0（0 表示不限制），但别长期设为 0 - 注意时区：计时窗口按 MySQL 服务器本地时间滚动，不是 UTC，也不是按自然小时（比如从 14:00–15:00），而是每个连接首次认证后开始计时的 3600 秒周期
替代方案：应用层限流比数据库限流更可控
MySQL 的 max_questions 是粗粒度硬限制，没有滑动窗口、无响应码区分、无法按 SQL 类型（如只限 SELECT）或路由路径（如只限 /search 接口）做策略，一旦触发直接断连。
生产环境更推荐在应用网关（如 Nginx + lua-resty-limit-traffic）、API 服务框架（如 Spring Cloud Gateway 的 RequestRateLimiter）或连接池层（如 HikariCP 配合自定义拦截器）实现细粒度限流。
- 数据库限流适合防误操作或兜底防护，不适合做业务级流量控制
- 如果必须用 MySQL 限流，建议配合
max_updates_per_hour和max_connections_per_hour组合使用，避免单点突增打垮库 - MySQL 8.0 开始支持角色（ROLE），但资源限制仍只能绑定到具体用户，不能绑定到角色上
