MAX_QUERIES_PER_HOUR 是 MySQL 原生账户级 SQL 执行频次限流机制,统计用户任意连续 60 分钟内所有语句总数,超限报错 ERROR 1226;建户用 CREATE USER WITH,改户用 ALTER USER WITH,设为 0 表示不限;失效主因是连接池复用、系统隐式查询计入、未刷权限或拼写错误。怎么用 MAX_QUERIES_PER_HOUR 限制用户每小时查询次数直接结论:max_queries_per_hour 是 mysql 原生支持的账户级限流机制,它统计的是「该用户账号在任意连续 60 分钟内发起的所有语句总数」(包括 select、show、explain,甚至某些隐式元数据查询),超限后立即报错 error 1226 (42000): user 'xxx' has exceeded the 'max_questions' resource。建用户时设置 vs 已有用户修改两种方式效果一致,区别只在时机:新建用户:CREATE USER 'api_user'@'%' IDENTIFIED BY 'pwd' WITH MAX_QUERIES_PER_HOUR 300;已有用户:ALTER USER 'report_user'@'localhost' WITH MAX_QUERIES_PER_HOUR 100;取消限制(恢复不限):ALTER USER 'user'@'host' WITH MAX_QUERIES_PER_HOUR 0;(注意:设为 0 才是"不限",不是省略)为什么你设了却没生效?常见踩坑点这个参数看似简单,但实际中失效频率很高,原因集中在三点:应用用了连接池(如 HikariCP、Druid)------MAX_QUERIES_PER_HOUR 是按「用户身份」累计,不是按连接或会话。一个连接反复执行 300 次 SELECT 就会触发限流,和连接数无关;系统自动查询也被计入:比如某些 ORM 启动时执行 SELECT DATABASE() 或 SHOW VARIABLES,这些都会消耗额度;未刷新权限:用 UPDATE mysql.user 直接改表后,必须执行 FLUSH PRIVILEGES;,而 CREATE/ALTER USER 不需要;注意拼写:错误写成 MAX_QUERY_PER_HOUR(少 s)或 MAX_QUESTIONS_PER_HOUR(旧别名,5.7+ 已弃用)会导致语法错误或静默忽略。MAX_QUERIES_PER_HOUR 和其他资源限制的区别它和同类参数不是互斥,而是各自独立计数: 文小言 百度旗下新搜索智能助手,有问题,问小言。
相关推荐
许彰午6 小时前
87_Python Django模型与数据库程序员小远6 小时前
性能测试之性能调优haluhalu.6 小时前
prompts.chat:02-anatomy-of-effective-prompt—Miss. Z—6 小时前
计算机二级MySQL选择题考点Ⅱ敖行客 Allthinker6 小时前
IM 融合专题:后端架构师的核心修炼金銀銅鐵6 小时前
[Python] 借助图形化界面探索模n运算的规律Hesionberger6 小时前
快速求解完全平方数的最少数量翔云1234566 小时前
MySQL 中 CURRENT_TIMESTAMP 到底取的是 INSERT 时间,还是 COMMIT 时间?矜持的左手6 小时前
硬件故障后数据文件大小不对故障处理—Oracle碎片扫描恢复xywww16810 小时前
大模型 API 选型实战:GPT、Gemini、Claude 接入时该看哪些指标?