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 和其他资源限制的区别它和同类参数不是互斥,而是各自独立计数: 文小言 百度旗下新搜索智能助手,有问题,问小言。
相关推荐
always_TT3 小时前
【Python 日志记录:logging 模块入门】建筑工程企业管理系统3 小时前
erp工程项目管理系统落地价值:实现工程多项目成本精细化核算与管控AI大模型-小华3 小时前
Codex 三方充值快速入门指南Bruce_Liuxiaowei4 小时前
轻量级 IOC 管理方案:Streamlit 驱动的恶意IP情报平台foolishlee4 小时前
Neon wal日志处理流程22601_965798475 小时前
Is Hygia Good for Maid & Janitorial Sites? Technical Auditlipku5 小时前
数字人直播开源项目LiveStreamCloud云卷云舒5 小时前
海山数据库(HaishanDB)面向工业云场景技术方案逃逸线LOF5 小时前
Spring配置数据源{连接池}(Druid、c3p0)阿童木写作6 小时前
Python实现亚马逊商品图批量智能抠图教程