max_updates_per_hour 是mysql用户级资源限制，仅限制insert、update、delete等写操作语句次数，不包括select/show；设为0表示不限制，修改后无需flush privileges，计数按自然小时重置。
max_updates_per_hour 是什么，限制的是哪类操作
它只限制「修改数据库或表结构/数据」的语句，比如 INSERT、UPDATE、DELETE、REPLACE、LOAD DATA、ALTER TABLE、DROP TABLE —— 但不包括 SELECT 或 SHOW 这类只读语句。这点和 MAX_QUERIES_PER_HOUR 完全不同，后者是“所有语句都算”。如果用户主要跑报表或查询服务，设这个参数基本没用；但如果是个写入密集型 API 账号（比如日志上报接口），它就非常关键。
怎么设置：CREATE USER 和 ALTER USER 都行，但时机很重要
新建用户时直接加限制最稳妥：CREATE USER 'log_writer'@'%' IDENTIFIED BY 'xxx' WITH MAX_UPDATES_PER_HOUR 200;
已有用户改用：ALTER USER 'log_writer'@'%' WITH MAX_UPDATES_PER_HOUR 150;
注意两点：
- 设置为 0 表示不限制（不是“禁用”，是“解除限制”）
- 修改后**不需要 FLUSH PRIVILEGES**，但资源计数器不会重置——已消耗的次数仍会计入当前小时窗口
- 如果用户正在执行长事务，且事务里包含多个 UPDATE，这些更新全部计入配额，哪怕事务还没提交
容易被忽略的坑：连接池、事务、报错时机
常见错误现象：ERROR 1226 (42000): User 'log_writer' has exceeded the 'max_updates' resource
这不是连接失败，而是语句执行到一半被 MySQL 主动拒绝——哪怕你刚连上、刚开事务、刚做第一个 UPDATE，只要本小时累计已达上限，立刻报错。
- 应用用了连接池（如 HikariCP、Druid）？MAX_UPDATES_PER_HOUR 不影响连接复用，只按语句执行次数累加，所以池子里 10 个连接一起刷 UPDATE，照样秒超
- 在一个事务里批量更新 100 行？算作 1 次 UPDATE 语句，不按行数计——但如果你写了 100 条独立的 UPDATE 语句，那就是 100 次
- 时间窗口是严格“自然小时”：从 UTC 时间 00:00 开始算，不是从首次连接开始滚动，也不支持自定义周期
和 MAX_QUERIES_PER_HOUR、MAX_USER_CONNECTIONS 的关系
它们互不干扰，各自独立计数：
- MAX_UPDATES_PER_HOUR 管写操作频次
- MAX_QUERIES_PER_HOUR 管所有语句总数（含 SELECT）
- MAX_USER_CONNECTIONS 管当前并发连接数（瞬时值）
- MAX_CONNECTIONS_PER_HOUR 管每小时新建立连接的次数（比如应用频繁启停连接）
实际中建议组合使用：比如对第三方调用账号，设 MAX_UPDATES_PER_HOUR 300 + MAX_USER_CONNECTIONS 3，既能防刷写，也能防连接耗尽。但别忘了——这些限制只在用户级生效，全局 max_user_connections 只是兜底，无法替代单个用户的精细控制。
