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替你做时区转换，应用层统一转成日期字符串再传进去，更可控。
