MySQL用户级连接频率限制靠GRANT或ALTER USER语句中的MAX_CONNECTIONS_PER_HOUR参数实现，仅作用于指定用户每小时的新连接数，不统计复用连接内的查询。
MySQL 用户级连接频率限制靠什么实现
MySQL 本身没有全局的 MAX_CONNECTIONS_PER_HOUR 配置项，这个参数只存在于用户账户的资源限制（GRANT 语句中），作用对象是单个 MySQL 用户，不是整个实例或外部脚本进程。它限制的是该用户每小时发起的**新连接数**，不包括复用连接池、长连接或已建立连接内的查询次数。
如何为脚本专用账号设置每小时最大连接数
必须先创建或修改用户，并在 GRANT 或 ALTER USER 中显式指定限制。直接改系统变量或配置文件无效。
CREATE USER 'script_user'@'%' IDENTIFIED BY 'pwd123' WITH MAX_CONNECTIONS_PER_HOUR 60;ALTER USER 'script_user'@'%' WITH MAX_CONNECTIONS_PER_HOUR 30;- 已有用户需先
GRANT权限再加限制，或用ALTER USER覆盖（MySQL 5.7.6+） - 限制生效需执行
FLUSH PRIVILEGES;（仅当手动修改 mysql.user 表时才必须；用CREATE/ALTER USER则自动生效）
为什么脚本可能完全不受限
常见失效场景不是配置错，而是没命中限制条件：
- 脚本用的是
root或其他未设限的账号 —— 限制只对指定用户生效 - 脚本复用连接（如 Python 的
pymysql.connect()后长期持有conn对象，反复execute()）——MAX_CONNECTIONS_PER_HOUR只统计CONNECT动作，不统计查询 - 连接来自 localhost，但账号定义为
'user'@'192.168.%'—— 主机名不匹配导致实际登录用了无限制的其他同名账号 - MySQL 版本低于 5.0.3 —— 该功能在此版本才引入，旧版忽略该参数
替代方案：真正控制脚本调用频次的实用做法
如果目标是防脚本高频轮询或误操作，用户级连接限频往往治标不治本。更可靠的方式是结合应用层和数据库外措施：
- 在脚本里加
time.sleep(1)或令牌桶逻辑，从源头控速 - 用代理层（如 ProxySQL）做连接速率限制，支持按 IP、用户名、SQL 模式多维限流
- Linux 层用
iptables或fail2ban限制源 IP 的新建连接频次（如-m connlimit --connlimit-above 10 --connlimit-mask 32） - 监控
SHOW STATUS LIKE 'Threads_connected';+ 告警，比依赖小时粒度的配额更及时
注意：MAX_CONNECTIONS_PER_HOUR 是硬限制，超限会直接报错 ERROR 1226 (42000): User 'xxx' has exceeded the 'max_connections_per_hour' resource，但它的计量窗口是整点对齐的（不是滑动窗口），这点容易被忽略。
