mysql服务端原生无法实现每小时查询次数限制，因max_questions为累计阈值且不自动重置；需在应用层用redis+lua原子计数，或通过proxysql/maxscale等代理层结合外部存储实现。
MySQL 8.0+ 中用 RESOURCE GROUP 配合 user_attributes 实现查询频率限制
MySQL 原生不支持“每小时最多 N 次查询”这种基于时间窗口的限流，max_questions 是按**累计次数**限制（比如每小时重置？不，它从用户创建或上次清零起一直累加），实际无法满足“每小时”这个动态窗口需求。真正可行的路径是：MySQL 8.0.29+ 提供了 user_attributes 字段 + RESOURCE GROUP 的组合能力，但注意——RESOURCE GROUP 只能限制 CPU/线程资源，**不能直接限制 SQL 执行频次**。
所以结论很明确：**MySQL 服务端原生无法实现每小时查询次数限制**。你必须在应用层或中间件拦截并计数。
为什么 max_questions 不等于“每小时最大查询数”
max_questions 是一个硬性累计阈值，一旦达到，后续所有 SELECT 都会报错 ERROR 1226 (42000): User 'u1' has exceeded the 'max_questions' resource (current value: 100)，直到管理员手动执行 ALTER USER 'u1'@'%' WITH MAX_QUERIES_PER_HOUR 0 清零，或者删除重建用户。它没有自动重置机制，也不区分语句类型（INSERT/UPDATE 也会计入）。
- 设置
MAX_QUERIES_PER_HOUR 100≠ 每小时最多 100 次，而是“一生最多 100 次 SELECT（及部分其他语句）” - 该限制对
PREPARE/EXECUTE语句同样生效，容易误伤预编译场景 - MySQL 5.7 及更早版本中，
max_questions甚至对SELECT ... INTO OUTFILE不计数，行为不一致
可行替代方案：应用层 Redis 计数 + Lua 原子操作
这是目前最稳定、可精确控制时间窗口的方式。核心逻辑是：每次查询前，在 Redis 中对 user:u1:hourly_qps 自增，并设置过期时间为 3600 秒；若返回值 > 100，则拒绝本次查询。
推荐用 Lua 脚本保证原子性，避免竞态：
local key = "user:" .. KEYS[1] .. ":hourly_qps"
local count = redis.call("INCR", key)
if count == 1 then
redis.call("EXPIRE", key, 3600)
end
if count > tonumber(ARGV[1]) then
return 0
end
return count
调用时：redis.eval(script, 1, "u1", 100)。返回 0 表示超限，非 0 表示当前计数。
- 务必用连接池复用 Redis 连接，否则网络延迟会显著拖慢 MySQL 查询路径
- 不要在 MySQL 触发器或存储过程中调用外部服务（如 Redis），MySQL 不支持同步外调
- 如果应用是多进程部署（如 Python gunicorn 多 worker），Redis 是唯一可靠的共享状态中心
Proxy 层方案：使用 ProxySQL 或 MaxScale 做请求级限流
如果你已部署 ProxySQL，可以在 mysql_query_rules 表中配合 apply_custom_rules 和 stats_mysql_query_rules 实现粗粒度限流，但注意：ProxySQL 本身不内置时间窗口计数器，仍需依赖外部存储（如 SQLite 内存表或后端 Redis）来维护每用户每小时计数。
MaxScale 的 qlafilter 插件支持基于正则匹配语句类型，但同样缺乏原生滑动窗口能力。真正落地时，还是得靠自定义脚本 + 外部计数服务。
最容易被忽略的一点：任何限流都应在**认证后、SQL 解析前**介入。如果放在应用日志里事后统计，或只监控 slow_log，就完全失去实时拦截意义。
