MySQL禁止在BEFORE UPDATE触发器中查询当前表的COUNT(*)，因InnoDB引擎级硬限制导致ERROR 1442；唯一可行方案是应用层预检频次并原子更新计数表，触发器仅作日志记录。
BEFORE UPDATE触发器里不能查当前表的COUNT(*)
MySQL明确禁止在BEFORE UPDATE触发器中对正被更新的表执行聚合查询，比如SELECT COUNT(*) FROM orders WHERE user_id = NEW.user_id AND DATE(updated_at) = CURRENT_DATE。一写就报ERROR 1442 (HY000): Can't update table 'orders' in stored function/trigger——这不是权限问题，是InnoDB引擎级硬限制。
常见错误包括：把统计逻辑塞进存储函数再调用、用子查询做IF条件、或试图在触发器里SELECT INTO变量后判断。全都会触发同一错误。
- 唯一能安全读写的对象是其他无关表（如日志表、独立计数表）
- NEW和OLD字段可用，但不能拿它们去查当前表的聚合结果
- 哪怕建了专用的
user_daily_update_count表，只要触发器语句里出现对它的SELECT COUNT(*)，且该表被当前UPDATE语句间接影响（比如外键关联），仍可能失败
真正可行的路径：应用层预检 + 触发器只记日志
每日更新频次限制必须由应用层承担核心判断逻辑，触发器只做轻量收尾。典型流程是：
应用收到UPDATE请求 → 先执行INSERT INTO user_daily_update_count (user_id, date, count) VALUES (?, CURRENT_DATE, 1) ON DUPLICATE KEY UPDATE count = count + 1 → 检查返回的Rows matched和Changed值 → 若更新后count > 5，直接回滚事务，不发后续UPDATE
-
user_daily_update_count表主键必须是(user_id, date)，并建唯一索引，否则ON DUPLICATE KEY UPDATE无法原子生效 - 触发器只在
AFTER UPDATE里往update_log表插入一条记录，不参与判断 - 如果业务允许改
user_id字段（如把订单从A用户转给B），应用层需额外校验目标用户当日剩余额度，触发器无法覆盖这种跨用户变更
CURRENT_DATE比DATE(NOW())更可靠，但别依赖USER()
时间判断必须用CURRENT_DATE，不是DATE(NOW())或DATE(updated_at)。前者是日期字面量，无时区/精度干扰；后两者在索引失效、字段为NULL、或字段类型是DATETIME但只存日期时都容易出错。
用户标识不能靠USER()或CURRENT_USER()——如果你用连接池或代理（如ProxySQL、HAProxy），所有请求看到的都是app_rw@'%'，根本分不清真实操作人。
- 必须在业务表里有显式字段，如
updated_by INT，且每次UPDATE都带SET updated_by = ? - 触发器里只能信任
NEW.updated_by，它是应用传入、已校验过的值 - 若字段名是
submitter_id或operator_id，就用对应NEW.submitter_id，别硬套通用名
并发与回滚会破坏计数准确性
哪怕你绕过ERROR 1442，硬用触发器去维护计数表，也会立刻掉进三个坑：
- 事务回滚时，触发器已执行的
UPDATE user_daily_update_count SET count = count + 1不会撤销 → 计数永久偏高 - 两个并发UPDATE同个用户，可能同时读到旧值
4，都+1写入 → 实际变成5但计数表里是6 - 客户端崩溃、网络中断、超时断连，都不会触发
AFTER UPDATE，导致日志缺失，但计数已加
这些不是边缘情况，而是高并发下的常态。所以不要幻想用触发器“全自动”控频——它连最基本的一致性都保不住。
