MySQL 触发器无法限制单日 UPDATE 次数，因 BEFORE UPDATE 时行已变更且无法跨事务统计，ERROR 1442 禁止触发器操作当前表；须用独立计数表 +INSERT … ON DUPLICATE KEY UPDATE 原子操作或 Redis 限流，强一致性场景必须选数据库计数表。
MySQL 触发器怎么限制单日 UPDATE 次数
直接用触发器拦不住——BEFORE UPDATE 触发时，行级变更已发生，且无法跨事务统计当天更新总数。真正可行的是把计数逻辑外移，用一张计数表 + 唯一约束或应用层预检。
常见错误现象：ERROR 1442 (HY000): Can't update table't' in stored function/trigger because it is already used by statement which invoked this stored function/trigger——这是 MySQL 硬限制，触发器里不能改当前表，也不能查当前表的聚合结果（如COUNT(*)）。
- 必须单独建一张限流计数表，比如
user_daily_update_count，字段含user_id、date、count - 每次 UPDATE 前，应用层先执行
INSERT …… ON DUPLICATE KEY UPDATE count = count + 1，主键为(user_id, date) - 如果返回影响行数为 0（即已达上限），就拒绝本次更新，不碰业务表
应用层限流该选 Redis 还是数据库计数表
Redis 快但不保证强一致；数据库表慢点但和业务事务可绑定。如果你的 UPDATE 本身走事务，且要求“超量就绝对不写”，那就必须用数据库计数表——否则 Redis 里 + 1 成功了，业务表写失败，第二天对不上账。
性能影响明显：每条 UPDATE 多一次 INSERT …… ON DUPLICATE KEY UPDATE，索引要建在 (user_id, date) 上，否则全表扫。别忘了加 ON CONFLICT DO UPDATE（PostgreSQL）或等价逻辑，MySQL 里就是 ON DUPLICATE KEY UPDATE。
- Redis 适合读多写少、允许短时超限的场景，比如后台任务限流
- 数据库计数表适合金融、订单类强一致性要求，哪怕吞吐降 20% 也得保准确
- 别用
SELECT + UPDATE两步走——竞态条件必然导致超限，必须原子操作
为什么不能只靠应用层判断用户当天更新了多少次
因为应用层没全局视图：多个服务实例、多线程、异步任务都可能同时操作同一用户，各自查自己缓存或本地变量，结果全错。
典型错误场景：A 服务查到用户今天更新了 49 次，准备第 50 次；B 服务也查到 49 次，也准备第 50 次；俩都写进去了——变成 51 次。只有带唯一约束的写入（如INSERT …… ON DUPLICATE KEY UPDATE）才能靠数据库锁住那一行，确保原子性。
- 本地内存计数（如
ConcurrentHashMap）完全不可信，重启就丢，多实例不同步 - 即使用了 Redis，也要用
INCR+EXPIRE配合，且设置好 key 过期时间为当日 24 点整，不能简单设 24h TTL - MySQL 里日期要用
CURDATE()，别用NOW()或字符串拼接，避免时区或格式错乱
触发器真的一点用都不能起吗
能起，但只能做兜底校验，不能当主力限流手段。比如在 AFTER UPDATE 里查计数表，发现超限就写日志、发告警，甚至调用存储过程回滚——但 MySQL 不允许在 AFTER 触发器里回滚当前事务，所以实际只能记录和通知。
容易被忽略的点：触发器里的 SELECT 查计数表，如果没走索引，高并发下会成热点。而你又没法在触发器里加 FOR UPDATE 锁行——会死锁。
- 触发器只适合审计、日志、异步通知，别指望它拦住超限操作
- 如果非要写，务必给计数表的
(user_id, date)加联合唯一索引，否则SELECT慢到拖垮整个表 - 上线前压测时，重点看计数表的
Rows_examined和Innodb_row_lock_waits指标
最麻烦的其实是时间边界——“一天”按什么算？UTC？服务器时区？用户所在时区？这个逻辑一旦定错，凌晨 0 点前后就会批量误判。别让 DB 替你做时区转换，应用层统一转成日期字符串再传进去，更可控。
