MySQL触发器无法安全限制每日操作次数，因其禁止在BEFORE UPDATE中查询正被修改的表（ERROR 1442）；正确做法是应用层用INSERT ... ON DUPLICATE KEY UPDATE预检并计数，触发器仅在AFTER UPDATE中记录日志。
MySQL触发器本身无法安全、可靠地限制每日操作次数——它不能跨事务读取聚合结果，也不能在BEFORE UPDATE中查当前表的COUNT(*)，否则直接报ERROR 1442。
为什么BEFORE UPDATE里查user_daily_count会失败
MySQL明确禁止在触发器中对“正在被语句修改的表”执行SELECT COUNT(*)或任何聚合查询。哪怕你建了一张user_daily_count表专门存计数，只要触发器写成SELECT COUNT(*) FROM user_daily_count WHERE user_id = NEW.user_id AND date = CURDATE()，就会触发ERROR 1442（Can't update table 't' in stored function/trigger...）。这不是权限问题，是引擎级硬限制。
常见错误做法：
- 在
BEFORE UPDATE里先SELECT ... INTO @cnt再判断 → 必然失败 - 试图用子查询
(SELECT count FROM user_daily_count WHERE ...) > 50做条件 → 同样触发ERROR 1442 - 把统计逻辑塞进存储函数再调用 → 函数内若含SELECT，仍属“访问当前表”，照样报错
真正能用的路径：只让触发器做原子更新，不查不判
触发器唯一可安全执行的操作是「单行、无聚合、不碰当前业务表」的写入。所以正确分工是：
- 应用层负责预检：每次UPDATE前，先执行
INSERT INTO user_daily_count (user_id, date, count) VALUES (?, CURDATE(), 1) ON DUPLICATE KEY UPDATE count = count + 1 - 触发器只干一件事：在
AFTER UPDATE里往日志表写一条记录，比如INSERT INTO op_log (user_id, op_type, op_time) VALUES (NEW.user_id, 'update', NOW(3)) - 拒绝逻辑必须放在应用层——如果
ON DUPLICATE KEY UPDATE返回Rows matched: 1 Changed: 1且更新后count > 50，就回滚整个事务
注意：user_daily_count的主键必须是(user_id, date)，且该组合字段要建唯一索引，否则ON DUPLICATE KEY UPDATE无法保证原子性。
用触发器维护计数表的三个高危陷阱
即使你坚持要用触发器更新计数表（比如想省掉应用层那一次SQL），也必须直面以下现实：
- 事务回滚时，触发器已执行的
UPDATE user_daily_count SET count = count + 1不会自动撤销 → 计数永久偏高 - 并发UPDATE同个用户时，两个触发器可能同时读到旧值，都+1写入 → 计数少算一次
- 连接异常断开、客户端崩溃、超时中断，都不会触发AFTER触发器 → 计数漏减，第二天仍不准
规避方法只有两个：SELECT ... FOR UPDATE锁住计数行（但会严重拖慢并发），或者彻底放弃触发器，改用应用层+Redis Lua脚本做原子限流（适合非强一致场景）。
替代方案选型：什么时候该用数据库计数表，什么时候该切Redis
如果你的业务要求“今天第51次UPDATE绝对不能落库”，就必须用数据库计数表，哪怕多一次INSERT ... ON DUPLICATE KEY UPDATE的IO开销。因为只有它能和业务UPDATE绑定在同一事务中，靠唯一索引和行锁保原子性。
但如果只是防刷、控后台任务频率，允许短时超限（比如1秒内多跑两次），Redis更轻量：
- 用
INCR user:123:update:2026-05-09+EXPIRE设24小时过期 - 用
GET user:123:update:2026-05-09查当前值，应用层判断是否>50 - 注意：Redis没事务，
INCR和EXPIRE需用Lua打包，否则可能计数有但没过期键
最容易被忽略的一点是：MySQL 8.0+ 的performance_schema.threads能实时看活跃连接，但它对“每日操作次数”毫无帮助——那是会话维度，不是业务行为维度。别把它和计数表混用。
