mysql触发器中禁止在after insert/delete里用count(*)更新统计表，应改用before触发器+增减计数逻辑，并确保统计表维度字段有唯一索引。
触发器里不能用 COUNT(*) 直接更新统计表
MySQL 触发器中禁止在 AFTER INSERT 或 AFTER DELETE 里对**同一事务中正在被修改的表**执行 SELECT COUNT(*) —— 这会触发 “Can’t update table ‘xxx’ in stored function/trigger” 错误。哪怕你查的是另一张表，只要涉及聚合函数且该表正被当前触发器上下文影响（比如级联或外键关联），也可能报错。
正确做法是绕过聚合查询，改用「增减计数」逻辑：
- INSERT 触发器：给统计字段 +1
- DELETE 触发器：给统计字段 −1
- UPDATE 触发器：需判断是否跨分区（比如
status从 'draft' → 'published'），按需 -1 再 +1
必须用 BEFORE 而非 AFTER 更新统计表
如果在 AFTER INSERT 中更新统计表，可能因并发写入导致计数错位（两个事务同时读到旧值、各自+1、再写回，结果只+1而非+2）。而 BEFORE 触发器能确保每次变更在数据落盘前就完成计数修正，天然串行化。
示例：对 orders 表按用户统计订单数，维护 user_stats 表：
CREATE TRIGGER tr_orders_insert BEFORE INSERT ON orders FOR EACH ROW INSERT INTO user_stats (user_id, order_count) VALUES (NEW.user_id, 1) ON DUPLICATE KEY UPDATE order_count = order_count + 1;
注意：ON DUPLICATE KEY UPDATE 依赖 user_stats.user_id 有唯一索引，否则会插入重复行。
UPDATE 触发器要检查 OLD 和 NEW 的关键字段变化
不是所有 UPDATE 都影响统计逻辑。比如只改了 order_notes 字段，不应触发计数变动；但若 status 从 'cancelled' 变为 'paid'，可能需从“取消数”减1、“有效数”加1。
关键点：
- 在
BEFORE UPDATE中用IF OLD.status != NEW.status THEN ...判断 - 避免在触发器里调用存储函数处理复杂逻辑（性能差、调试难）
- 如果统计维度多（如按状态、按月份），建议拆成多个独立字段，不要用 JSON 或逗号分隔字符串存
统计表主键和索引设计直接影响触发器性能
每条 INSERT/DELETE 都会额外触发一次 UPDATE 或 INSERT ... ON DUPLICATE KEY UPDATE，若统计表没建好索引，这个操作会变成全表扫描。
必须确保：
- 统计表的维度字段（如
user_id、category_id）是主键或有唯一索引 - 避免用
VARCHAR(255)做统计键（哈希索引效率低），优先用整型 ID - 如果统计粒度是“每天每个用户”，组合索引应为
(user_id, date)，而非(date, user_id)（范围查询时前者更高效）
触发器本身不解决高并发下的锁竞争问题——当大量写入同一 user_id 时，user_stats 行会成为热点。这时得考虑异步汇总或分桶计数，而不是硬扛在触发器里。
