MySQL 8.0+ 原生支持通过 CREATE USER 或 ALTER USER 配合 MAX_QUERIES_PER_HOUR 限制用户每小时查询总数，按自然小时滚动重置，统计所有连接的 SELECT/INSERT/UPDATE/DELETE 等语句，超限报错 ERROR 1226，设为 0 表示不限。
MySQL 8.0+ 中用 CREATE USER 配合 MAX_QUERIES_PER_HOUR 限制查询频次
MySQL 原生支持基于用户的每小时查询次数限制，但仅限 MySQL 8.0 及以上版本，且必须在创建用户时或通过 ALTER USER 显式设置。5.7 及更早版本不支持该功能（即使文档里写了，实际无效）。
关键点：这个限制作用于「该用户所有连接的总和」，不是单个连接；它统计的是成功执行的语句（SELECT、INSERT、UPDATE、DELETE 等），不包括 SHOW、SET 或语法错误的语句。
- 创建带限制的新用户：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd123' WITH MAX_QUERIES_PER_HOUR 300;
- 修改已有用户：
ALTER USER 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 120;
- 查看当前用户的资源限制：
SELECT user, host, max_questions FROM mysql.user WHERE user = 'api_user';
- 取消限制（设为 0 表示无限制）：
ALTER USER 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 0;
为什么 FLUSH PRIVILEGES 不起作用？
资源限制（MAX_QUERIES_PER_HOUR 等）是存储在 mysql.user 表里的持久化配置，不是内存缓存，所以不需要也不应该执行 FLUSH PRIVILEGES —— 这个命令只刷新权限缓存（如 GRANT 相关字段），对资源限制字段完全无效。
常见误操作：改完 ALTER USER ... WITH ... 后立刻 FLUSH PRIVILEGES，然后发现限制没生效。其实只要语句执行成功，限制就已写入表并立即生效（新连接会遵守，已有连接在下一次查询时触发检查）。
- 验证是否写入成功，直接查
mysql.user表的max_questions字段 - 旧连接可能还在用旧配额，建议让应用重连一次
- 如果用的是代理（如 ProxySQL、MaxScale），注意它们可能绕过 MySQL 的原生限流逻辑
遇到 User 'xxx' has exceeded the 'max_questions' resource 错误怎么办
这个错误说明用户当小时累计查询数已超限，后续查询会被拒绝，直到 UTC 时间进入下一小时（不是自然小时，是按 MySQL 服务启动后整点滚动计算的小时窗口）。这点容易被忽略——它不按北京时间/本地时间归零，而是按 MySQL 内部计时器滚动。
- 临时缓解：提高限额或设为 0，再观察业务是否真有突发流量
- 长期方案：确认是否应限制“查询次数”而非“连接数”或“CPU 时间”——比如高频
SELECT COUNT(*)小查询很容易触顶，但代价很低；此时更适合用MAX_UPDATES_PER_HOUR或监控慢查询 - 注意：该限制对
root用户同样有效，别在管理账号上误配导致运维中断
替代方案：应用层限流比数据库层更可控
MySQL 的 MAX_QUERIES_PER_HOUR 是粗粒度开关，无法区分 SQL 类型、无法按 IP/路径分流、不能动态调整、也没有详细日志记录谁在哪一秒打满了额度。生产环境真正需要精细控制时，几乎都会退回到应用层或中间件做限流。
- 例如：用 Redis + Lua 实现滑动窗口计数，按
user_id:hour或token:minute维度统计 - API 网关（Kong、APISIX）可配置 per-consumer 速率限制，支持响应码拦截、降级策略
- 如果必须走 DB 层，可考虑
max_connections或max_updates_per_hour配合业务语义更匹配的维度
真正上线前，务必在测试环境用脚本模拟高并发查询，确认错误出现时机和恢复逻辑是否符合预期——MySQL 的小时重置机制和错误抛出时机，在压测中才容易暴露出来。
