MySQL用户级更新频率限制通过CREATE USER或ALTER USER语句中的MAX_UPDATES_PER_HOUR子句实现，仅对非SUPER权限用户生效，按自然小时滚动统计，0表示禁止UPDATE，正整数表示每小时允许的UPDATE语句条数。
MySQL 用户级更新频率限制靠什么实现
MySQL 没有 MAX_UPDATES_PER_HOUR 这个配置项，它根本不存在。你查文档、看错误日志、甚至翻源码都找不到这个变量——这是常见误解的源头。真正可用的是账户资源限制（resource limit），通过 CREATE USER 或 ALTER USER 的 MAX_UPDATES_PER_HOUR **子句**（注意：是语法子句，不是系统变量）来设置，但它控制的是「该用户每小时能执行多少条 UPDATE 语句」，且仅对非 SUPER 权限用户生效。
如何正确设置每小时 UPDATE 语句数上限
必须在创建或修改用户时显式声明，运行时无法动态开启或调整该限制（除非重跑 ALTER USER）。限制值为整数，0 表示“禁止任何 UPDATE”，正整数表示每小时允许的最大语句数（不是行数，是一条 UPDATE 语句算一次，哪怕它影响 1000 行）。
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_UPDATES_PER_HOUR 300;ALTER USER 'api_user'@'%' WITH MAX_UPDATES_PER_HOUR 120;- 已存在的用户若没设过该限制，默认为 0？不对——默认是「不限制」，即无上限；只有显式设置了才生效
- 该限制只作用于
UPDATE语句，INSERT、DELETE、REPLACE各自需单独用MAX_INSERTS_PER_HOUR等子句控制
为什么执行 UPDATE 没被拦住？常见失效原因
即使设了 MAX_UPDATES_PER_HOUR，你也可能完全感知不到限制效果——因为 MySQL 不会提前报错，而是在超限时直接拒绝执行并返回错误。
- 错误信息是：
ERROR 1226 (42000): User 'xxx' has exceeded the 'max_updates_per_hour' resource (current value: N) - 限制按「自然小时」滚动计算，不是从第一次 UPDATE 开始计时，而是基于服务器当前时间点（如 14:00–15:00 为一个窗口）
- 如果你用的是连接池（如 HikariCP、Druid），多个连接共享同一用户身份，限制是按用户维度汇总统计的，不是单连接独立计数
- 拥有
SUPER权限的用户完全绕过所有资源限制（包括此条），检查权限用：SHOW GRANTS FOR 'user'@'host';
替代方案：应用层限流更可控
数据库原生的 MAX_UPDATES_PER_HOUR 粗粒度高、不可监控、不可重置、不支持分组或条件策略，生产环境很少依赖它做核心限流。真要控频，优先考虑：
- 在业务代码里用 Redis + Lua 做滑动窗口计数（比如
INCR+EXPIRE组合） - API 网关层统一拦截（如 Nginx 的
limit_req，或 Spring Cloud Gateway 的RequestRateLimiter） - 如果必须用 MySQL 控制，可建触发器+计数表模拟，但会增加写开销和死锁风险，不推荐
别在用户权限语句里写 MAX_UPDATES_PER_HOUR 期待它像防火墙一样实时拦截——它只是个低优先级的兜底开关，且容易被忽略的权限、连接复用、时间窗口机制掩盖真实行为。
