结论：AFTER INSERT触发器做多表汇总必须仅更新目标汇总表、禁止触碰原表或JOIN、每行只改一条记录，并提前建好覆盖全部维度的联合主键；否则会漏数据或写错行。
直接说结论：用 AFTER INSERT 触发器做多表汇总累加，必须只更新目标汇总表、禁止碰原表或 JOIN、每行只改一条记录，且要提前建好覆盖全部统计维度的联合主键——否则不是漏数据就是写错行。
为什么不能在触发器里跑 SUM() 或 JOIN 查询
触发器运行在单行上下文里，NEW 只能看到刚插入的那一行。你没法在 orders 表的 AFTER INSERT 触发器里写 SELECT COUNT(*) FROM orders JOIN users ON ...，MySQL 会报语法错误或读到脏数据。更关键的是：这类聚合查询会锁表、拖慢插入性能，高并发时可能卡住整个写入链路。
常见错误现象：
- 汇总值比实际少（子查询没查全或被事务隔离级别挡住了）
- 插入变慢，SHOW PROCESSLIST 看到大量 Waiting for table metadata lock
- 多个触发器同时更新同一张汇总表，出现“丢失更新”
正确做法是把统计逻辑拆到应用层或定时任务，触发器只干一件事：基于当前这行数据，对汇总表做单点 +1 或 +amount。
AFTER INSERT 触发器里怎么安全更新汇总表
假设你有 orders 表，想按 customer_id 和 status 实时累加订单数和金额到 summary_by_customer_status 表。这张汇总表必须定义联合主键：PRIMARY KEY (customer_id, status)。
实操建议：
- 用 INSERT INTO ... ON DUPLICATE KEY UPDATE 替代 UPDATE，避免因主键不存在而静默失败
- 所有字段更新都基于 NEW，不查原表、不调子查询
- 显式处理 NULL：比如 IFNULL(NEW.amount, 0)
- 不在触发器里做跨库写入（如 INSERT INTO other_db.summary ...），RDS 等托管服务常禁用
示例语句：
CREATE TRIGGER trg_orders_after_insert_summary<br>AFTER INSERT ON orders<br>FOR EACH ROW<br>BEGIN<br> INSERT INTO summary_by_customer_status (customer_id, status, order_count, total_amount)<br> VALUES (NEW.customer_id, NEW.status, 1, IFNULL(NEW.amount, 0))<br> ON DUPLICATE KEY UPDATE<br> order_count = order_count + 1,<br> total_amount = total_amount + IFNULL(NEW.amount, 0);<br>END;
INSERT IGNORE / REPLACE 会跳过触发器，这点最容易被忽略
INSERT IGNORE 和 REPLACE INTO 对于因唯一键冲突而跳过的行，**完全不触发任何触发器**。这意味着：
- 你指望靠触发器维护的汇总值，那些被 ignore 的行就永远不同步
- REPLACE 实际是先 DELETE 再 INSERT，只触发 BEFORE DELETE 和 AFTER INSERT，中间状态丢失，OLD.amount 在 DELETE 阶段才可见，但 INSERT 阶段又没了
所以：
- 统计类场景一律禁用 INSERT IGNORE 和 REPLACE
- 必须用 INSERT ... ON DUPLICATE KEY UPDATE，它保证每次都会走 AFTER INSERT
- 如果业务真需要“存在则跳过”，得在应用层判断，别甩给数据库
多个子表共用一张汇总表时，触发器要各自独立、互不干扰
比如 orders_online 和 orders_offline 都要往 summary_total 更新。不能让两个触发器都去 UPDATE summary_total SET total = total + NEW.amount——没有 WHERE 条件会扫全表；也不能共用同一个触发器名或逻辑分支。
要点：
- 每个源表配一个专属触发器，命名带表名前缀（如 trg_orders_online_after_insert）
- 汇总表主键必须能区分来源（例如加 source_type ENUM('online','offline') 字段）
- 同一维度下多张子表更新同一汇总字段？那就只能在应用层合并，或者用定时任务兜底，触发器不适合这种模式
- 测试时务必用 SELECT ... FOR UPDATE 模拟并发插入，看会不会出现 total_amount 少加
真正难的不是写触发器，而是确认业务允许“差值累加”。如果字段含义不是严格可加（比如平均值、最新时间戳、JSON 合并），就别硬套这个模式——该上物化视图或应用层聚合，就别在触发器里死磕。
