如何配置用户的资源使用上限_MAX_QUERIES_PER_HOUR查询频率限制

MySQL 8.0+ 仅支持通过 CREATE/ALTER USER ... WITH MAX_QUERIES_PER_HOUR 设置频率限流，按自然小时统计语句总数，不区分类型、不看耗时，不可自定义窗口；GRANT ... WITH 已废弃且逻辑危险，应禁用。MySQL 8.0+ 怎么给用户加 MAX_QUERIES_PER_HOUR 限制直接用 CREATE USER 或 ALTER USER 设置，这是唯一原生支持的“频率限流”方式。它不拦单条慢查询，只卡单位时间内的语句总数——适合防轮询、脚本误跑、爬虫扫库这类高频轻量请求。实操建议：CREATE USER 'api_user'@'%' WITH MAX_QUERIES_PER_HOUR 120; —— 新建用户时直接绑定，最干净ALTER USER 'report_user'@'localhost' WITH MAX_QUERIES_PER_HOUR 300; —— 已有用户可随时调整，无需重连该限制对所有语句生效（SELECT/INSERT/UPDATE/DELETE/SET 都算），但 COMMIT、ROLLBACK、SHOW 等不计入注意：不是每秒或每分钟，是严格按“自然小时”滚动（从 00:00 开始计数），不能自定义窗口为什么 GRANT ... WITH MAX_QUERIES_PER_HOUR 在 MySQL 8.0+ 不推荐用这个语法在 5.7 是合法的，但在 8.0+ 已被废弃，且逻辑极容易踩坑：它只对当前 GRANT 语句中显式列出的权限生效，没列的权限完全不受限。比如你写 GRANT SELECT ON db.* TO u@h WITH MAX_QUERIES_PER_HOUR 100;，那用户后续如果还有 UPDATE 权限（来自另一条 GRANT），更新操作就完全绕过限制。更糟的是，多个 GRANT 记录共存时，系统取的是各条里最大的值，不是累加，查问题时数值对不上，调试成本高。所以：一律用 CREATE/ALTER USER ... WITH，别碰带 WITH 的 GRANT。MAX_QUERIES_PER_HOUR 真的能防住大查询吗不能。它只计数，不看执行时间、不看扫描行数、不看内存占用。一条 SELECT SLEEP(30) 算 1 次，一条 SELECT * FROM huge_table WHERE ... 也只算 1 次。真正耗资源的大查询，它完全不管。 通义听悟 阿里云通义听悟是聚焦音视频内容的工作学习AI助手，依托大模型，帮助用户记录、整理和分析音视频内容，体验用大模型做音视频笔记、整理会议记录。