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_userlocalhost 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 uh 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助手依托大模型帮助用户记录、整理和分析音视频内容体验用大模型做音视频笔记、整理会议记录。