postgresql触发器维护聚合表必须严格区分操作类型、处理null、初始化数据且无法响应truncate；after触发器是唯一安全时机，需显式判断null、old/new值联动更新、用on conflict防重复，并额外处理truncate和历史数据初始化。
PostgreSQL 触发器能实时维护聚合表，但必须严格区分操作类型、处理 NULL、初始化数据，且无法响应 TRUNCATE —— 这些不是可选项，而是不补全就会出错的硬性前提。
为什么 AFTER INSERT/UPDATE/DELETE 触发器常算错总数
聚合值偏高或丢失，往往是因为没处理 NULL 参与运算。比如源表字段 amount 允许为 NULL，而触发器里直接写 total_sales = total_sales + NEW.amount，结果 NULL + 数值 得到 NULL，整行更新失败或静默丢弃。
- 必须显式判断：
NEW.amount IS NOT NULL才参与累加 - UPDATE 场景要同时考虑
OLD.amount和NEW.amount：先减旧值、再加新值，否则单次更新会重复计算 - INSERT 时若目标聚合行尚不存在，需用
INSERT ... ON CONFLICT DO UPDATE替代单纯UPDATE，避免报错
BEFORE vs AFTER 触发器在聚合场景中怎么选
聚合逻辑几乎全部应放在 AFTER 触发器里。用 BEFORE 做聚合不仅多余，还容易引发竞态或重复更新。
-
BEFORE INSERT/UPDATE适合做校验（如拒绝负金额）、默认值填充（如自动设created_at），但不能用于修改聚合表——此时聚合表还没看到新数据，无法正确计算 -
AFTER是唯一安全时机：源行已落库，NEW和OLD值稳定，可放心读写汇总表 - 混用
BEFORE和AFTER更新同一张汇总表，极大概率导致双计（double-count）——例如一个订单先被BEFORE加了一次，AFTER又加一次
TRUNCATE 操作完全绕过普通触发器
TRUNCATE 不触发任何 INSERT/UPDATE/DELETE 类型的触发器，这是 PostgreSQL 的明确设计行为，不是 bug。
- 如果业务允许执行
TRUNCATE，就必须额外建EVENT TRIGGER监听sql_drop事件，再手动清空或重建聚合表 - 更常见的做法是：禁用
TRUNCATE权限，并在文档中明确要求“清空请用DELETE FROM”，确保走触发器路径 - 哪怕只删掉一行，也比
TRUNCATE安全——因为至少能触发AFTER DELETE
新建聚合表后必须手动初始化，不能等触发器“慢慢补”
触发器只响应后续 DML，对已有历史数据无感知。刚建好 daily_sales_summary 表时它是空的，哪怕源表有三年销售记录，触发器也不会倒推计算。
- 必须立刻执行一次
INSERT INTO daily_sales_summary SELECT sale_date, SUM(amount) FROM sales GROUP BY sale_date - 这条语句建议加
ON CONFLICT DO UPDATE，以防重复初始化破坏一致性 - 如果源表数据量极大，初始化过程可能锁表或耗时长，应安排在低峰期，并确认事务不会超时
真正麻烦的从来不是写触发器语法，而是想清楚“哪些变更它看不见”——TRUNCATE、批量 COPY、跨事务的并发更新、以及最常被忽略的初始化缺口。这些地方一漏，聚合值就再也追不回来了。
