max_queries_per_hour是MySQL原生账户级限流机制，统计用户任意连续60分钟内所有语句总数，超限报错ERROR 1226；设为0表示不限，需用CREATE/ALTER USER WITH配置，失效主因是连接池复用、隐式查询计入、未刷权限或拼写错误。
max_queries_per_hour 是什么，它真能限频吗
max_queries_per_hour 是 MySQL 用户级资源限制参数，作用是限制一个用户账户每小时最多执行多少条语句（包括 SELECT、INSERT、UPDATE、DELETE 等所有非管理类语句）。它**不能精确控制“查询频率”**（比如每秒最多 5 次），也不能区分 SELECT 和其他操作——只要语句被服务器接受并进入执行队列，就算一次计数。
常见误解是把它当 API 限流用，结果发现慢查询、批量导入、连接复用场景下限流失效或误伤。它本质是粗粒度的配额制，适合防止长期滥用，不适合实时防刷或 QPS 控制。
怎么给用户设置 max_queries_per_hour
必须用 GRANT 语句重置权限才能生效，不能直接改 mysql.user 表后 FLUSH PRIVILEGES（该字段不走权限缓存刷新路径）。
- 新建用户并限制：
CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd';<br>GRANT SELECT ON mydb.* TO 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 3600;
- 修改已有用户：
GRANT SELECT ON mydb.* TO 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 1800;
（注意：必须包含已有权限，否则会覆盖掉之前的GRANT） - 设为 0 表示不限制（MySQL 默认值），设为正整数才启用限制
为什么设置了却没生效
这是最常踩的坑。max_queries_per_hour 生效有严格前提：
- 用户必须通过
GRANT ... WITH MAX_QUERIES_PER_HOUR N显式赋予权限，仅在CREATE USER时指定无效 - 限制只对“当前账号+主机组合”生效，
'user'@'192.168.%'和'user'@'192.168.1.100'视为不同用户，需分别设置 - MySQL 8.0+ 中，如果用户使用了角色（ROLE），限制必须加在角色上，而非用户本身
- 某些客户端（如某些 ORM 或连接池）会复用连接并自动发送
SELECT @@version类探测语句，这些也会被计入配额，导致“没查几次就超限”
超限后会发生什么，怎么确认是它导致的失败
用户执行第 N+1 条语句时，MySQL 直接返回错误：
User 'api_user' has exceeded the 'max_questions' resource (current value: 3600)
注意错误信息里写的是 max_questions，这是该限制在错误码中的历史名称，和配置项名不一致，容易让人困惑。
排查建议：
- 查用户当前限制：
SELECT User, Host, max_questions FROM mysql.user WHERE User = 'api_user';
- 检查是否刚改过权限但没重新登录：限制只在新连接中生效，旧连接不受影响
- 注意计时窗口是自然小时（从连接建立时刻起算 3600 秒），不是整点重置，无法对齐业务周期
真正需要按秒/分钟控频的场景，max_queries_per_hour 不是解法——得靠应用层限流、Proxy（如 ProxySQL）、或 MySQL Router 配合外部规则。这个参数只适合兜底防呆，别指望它扛住真实流量压力。
