mysql如何限制用户每小时的最大查询次数_配置MAX_QUERIES_PER

max_queries_per_hour是mysql原生账户级限流机制，统计用户任意连续60分钟内所有语句总数，超限报错error 1226；设为0表示不限，需用create/alter user with配置，失效主因是连接池复用、隐式查询计入、未刷权限或拼写错误。

mysql如何限制用户每小时的最大查询次数_配置max_queries_per_hour参数

直接结论：用 CREATE USER 或 ALTER USER 配置 MAX_QUERIES_PER_HOUR 是唯一原生、有效的方式；设为 0 才是不限，不是留空或省略；它统计的是「该用户账号在任意连续 60 分钟内发起的所有语句总数」，超限立刻报错 ERROR 1226 (42000)。

为什么刚设完就失效？常见失效原因

这个参数看着简单，但实际中“设了等于没设”很常见，核心问题不在语法，而在执行上下文：

应用用了连接池（如 HikariCP、Druid）——MAX_QUERIES_PER_HOUR 按「用户身份」累计，不是按连接或会话。一个连接反复执行 300 次 SELECT 就会触发限流，和你开了 1 个还是 100 个连接无关
ORM 或框架启动时的隐式查询（比如 SELECT DATABASE()、SHOW VARIABLES LIKE 'sql_mode'）也会被计入额度，可能还没正式跑业务就耗掉几十次
如果误用 UPDATE mysql.user 直接改表，必须手动执行 FLUSH PRIVILEGES；而 CREATE/ALTER USER 不需要这步，漏了就白配
拼写错误：写成 MAX_QUERY_PER_HOUR（少 s）或 MAX_QUESTIONS_PER_HOUR（旧别名，5.7+ 已弃用）会导致语法报错或静默忽略

CREATE USER 和 ALTER USER 的实操差异

两者效果完全一致，区别只在时机和权限要求：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

新建用户时绑定最干净：CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 300;
已有用户随时可调：ALTER USER 'report_user'@'localhost' WITH MAX_QUERIES_PER_HOUR 100;
取消限制必须显式设为 0：ALTER USER 'user'@'host' WITH MAX_QUERIES_PER_HOUR 0;（设为 NULL 或不写，不会清空）
ALTER USER 要求你有 SYSTEM_USER 或 ALTER USER 权限；CREATE USER 还需 CREATE USER 权限

它和 MAX_CONNECTIONS_PER_HOUR、MAX_UPDATES_PER_HOUR 的关系

它们互不干扰，各自独立计数，任一超限都会失败，没有降级逻辑：

MAX_QUERIES_PER_HOUR：统计所有语句（SELECT/INSERT/UPDATE/DELETE/SET），但 COMMIT、ROLLBACK、SHOW 不计入（注意：部分 SHOW 如 SHOW TABLES 会被计入，行为因版本略有差异）
MAX_CONNECTIONS_PER_HOUR：只统计成功认证的 mysql_real_connect() 调用次数（即「新连上 MySQL」的动作），不能用 ALTER USER 改，必须用 GRANT USAGE ON *.* TO 'u'@'h' WITH MAX_CONNECTIONS_PER_HOUR N; + FLUSH PRIVILEGES
MAX_UPDATES_PER_HOUR：只计 INSERT/UPDATE/DELETE/REPLACE，对读多写少的 API 场景意义有限，但适合防误删脚本