postgresql触发器不会丢失数据，但并发更新易致聚合错、null未处理、truncate绕过等不一致现象；after update累加出错主因是null参与运算导致结果为null，须显式判断new.amount is not null并同步处理old值。
PostgreSQL 触发器本身不会“丢失数据”，但并发更新下容易出现聚合值错、覆盖写入、NULL 未处理、TRUNCATE 绕过等现象，最终表现为数据不一致或看起来“丢了”。
为什么 AFTER UPDATE 触发器里累加会算错总数
最常见的是 NULL 参与运算导致整行更新静默失败或设为 NULL。比如源表 sales.amount 允许为 NULL，触发器写 total = total + NEW.amount，实际执行时变成 total = total + NULL → 结果为 NULL，后续再累加仍为 NULL。
- 必须显式判断：
IF NEW.amount IS NOT NULL THEN total = total + NEW.amount; - UPDATE 场景还要减旧值：
total = total - OLD.amount + NEW.amount，否则单次修改被重复计入 - INSERT 时目标行可能不存在，直接
UPDATE会失败，得用INSERT ... ON CONFLICT DO UPDATE
为什么 BEFORE UPDATE 触发器改了字段，主语句的值却没生效
BEFORE 触发器中对 NEW.xxx 的赋值会完全覆盖 SQL 语句中指定的值——不是“合并”，而是“替换”。如果你在触发器里写了 NEW.status = 'pending'，哪怕原语句是 UPDATE orders SET status = 'paid'，最终入库的仍是 'pending'。
- 这不是丢失，是覆盖逻辑没写全：若想“仅当余额不足时才设 pending”，就得把所有分支都写出来，不能只写一个
IF - AFTER 触发器无法修改当前行，
UPDATE同一表会报错Can't update table 'orders' in stored function/trigger - 别在 BEFORE 里查大表或做复杂计算，延迟会拖慢整个事务链路
为什么 TRUNCATE 表后聚合数据全空了，触发器却没反应
TRUNCATE 是 DDL 操作，PostgreSQL 明确规定它不触发任何 INSERT/UPDATE/DELETE 类型的触发器——这不是 bug，是设计行为。
- 即使你建了
AFTER DELETE触发器，TRUNCATE也不会调用它 - 必须额外建
EVENT TRIGGER监听sql_drop事件，或干脆禁用TRUNCATE权限，强制业务走DELETE FROM - 新建聚合表后必须手动初始化，触发器不会倒推历史数据
为什么高并发下同一行被多次更新，结果却像“丢了一次”
这不是触发器的问题，而是 PostgreSQL 默认隔离级别（READ COMMITTED）下，多个事务读到同一快照后各自提交，后提交者覆盖先提交者的修改——典型“写偏移（write skew）”。触发器只是被动执行，无法感知其他并发事务的存在。
- 触发器内不做锁，就无法阻止这种覆盖；加
SELECT ... FOR UPDATE可以，但会阻塞、可能死锁 - 应用层需配合重试（捕获
serialization_failure或deadlock_detected） - 真正安全的做法是：关键字段加
FOR UPDATE锁住行，或改用乐观锁（如版本号字段）
触发器的执行时机和上下文是固定的，它不创造新事务、不切换隔离级别、不自动重试。所有“丢失”的表象，其实都是对触发器生命周期和 MVCC 行为理解偏差导致的误操作——尤其是把 BEFORE 当成校验入口、把 AFTER 当成自由更新区、以及默认 TRUNCATE 也会触发逻辑。
