mysql触发器中禁止事务控制汇总表更新，因递归和死锁限制；须在触发器内直接写单行、单点更新逻辑，避免聚合查询、多表join、跨表操作及混合insert/update/delete处理，主键需覆盖全部统计维度并用insert...on duplicate key update保障并发安全。
触发器里不能用事务控制汇总表更新
MySQL 的 AFTER INSERT 或 AFTER UPDATE 触发器里，如果对另一张表（比如汇总表）做 INSERT/UPDATE，而该操作又触发了其他触发器或外键约束，容易引发“Cannot update table in stored function/trigger”的错误。这不是权限问题，是 MySQL 为防止递归和死锁做的硬限制。
- 避免在触发器中调用存储过程来更新汇总表，哪怕那个过程里只有一句
UPDATE - 汇总逻辑必须写在触发器体内，且只操作目标汇总表，不碰原表或其他关联表
- 如果原表有级联更新（如
ON UPDATE CASCADE），要确认它不会间接触发同一张汇总表的写入
多表 JOIN 统计值不能直接塞进触发器
触发器运行在单行上下文里，NEW 和 OLD 只能看到当前被变更的那一行数据。你无法在 orders 表的触发器里直接跑 SELECT COUNT(*) FROM orders o JOIN users u ON o.user_id = u.id WHERE u.level = 'vip' —— 这种聚合查询既慢又不可靠，还可能读到未提交的数据。
- 触发器里只基于
NEW.user_id做单点查找，比如查users表确认该用户是否 VIP，再决定要不要给summary_vip_order_count加 1 - 不要在触发器里写带
GROUP BY或子查询的统计 SQL，它们不是为行级触发设计的 - 如果统计依赖多个维度（如按月+按地区），触发器里只更新对应维度组合的那一条记录，别试图“重算全量”
INSERT/UPDATE/DELETE 三类操作要分开处理
同一个业务动作（比如用户下单）可能走 INSERT，但后续修改订单状态可能是 UPDATE，取消订单则是 DELETE。这三类操作对汇总值的影响方向不同，混在一个触发器里极易出错。
-
BEFORE INSERT：通常不用；AFTER INSERT适合加总数（如total_orders += 1） -
AFTER UPDATE：重点检查关键字段变化，比如IF OLD.status != NEW.status AND NEW.status = 'paid'，才去更新成交金额汇总 -
AFTER DELETE：必须回退之前加上的值，注意空值判断（IF OLD.amount IS NOT NULL） - 不要用一个
IF ... ELSEIF ... ELSE把三类逻辑全塞进一个触发器，维护时容易漏分支
汇总表主键设计不当会导致重复写入或丢失更新
汇总表如果没有明确、稳定的主键，或者主键没覆盖所有统计维度，就会出现多条记录对应同一统计口径，或者更新时找不到目标行而静默失败。
- 主键必须是业务可枚举的组合，比如
(year_month, region_code, user_tier)，而不是自增 ID + 一堆字段 - 用
INSERT ... ON DUPLICATE KEY UPDATE替代先SELECT再INSERT/UPDATE，避免并发冲突 - 如果统计维度可能为空（如
region_code为NULL），要在建表时明确UNIQUE KEY (year_month, region_code, user_tier)允许 NULL 组合唯一 —— 否则 MySQL 会认为多个NULL是不同值，导致重复插入
