必须写在order_items表上，因总金额变化仅由明细增删改触发；orders表上的直接更新会绕过业务逻辑，导致触发器无法捕获。
触发器该写在订单表还是订单明细表
必须写在 order_items（订单明细）表上，而不是 orders 表。因为总金额变化只由明细的增删改触发——新增一行商品、修改数量、删除某项，都会影响合计值；而直接更新 orders.total_amount 属于绕过业务逻辑的危险操作，触发器无法捕获。
常见错误是把触发器建在 orders 表上，结果插入明细后总金额完全不更新。
- INSERT：需累加新行的
quantity * unit_price - UPDATE：先减去旧值，再加新值（不能只加差额，因
unit_price或quantity都可能变） - DELETE：减去被删行的金额
MySQL 中 BEFORE 还是 AFTER 触发器更安全
用 BEFORE INSERT/UPDATE/DELETE。这样可以在变更生效前就修正 orders.total_amount，避免出现“明细已插、但总金额没同步”的短暂不一致状态。
如果用 AFTER，并发插入时可能多个事务同时读到旧的 total_amount，再各自叠加，造成金额重复累加。
-
BEFORE INSERT：查出对应order_id当前总金额，加上新行金额后写回orders -
BEFORE UPDATE：用OLD.quantity * OLD.unit_price减去旧值，再用NEW.quantity * NEW.unit_price加上新值 -
BEFORE DELETE：直接减去OLD.quantity * OLD.unit_price
如何避免触发器里更新主表引发递归或死锁
MySQL 默认禁止触发器内修改当前表，但允许改其他表。所以更新 orders 是安全的；但要注意两点：
- 确保
orders表有主键（如id），且触发器中用WHERE id = NEW.order_id精确更新，别用模糊条件 - 不要在触发器里调用存储过程或函数，如果它们内部又去写
order_items，会触发新一轮触发器，导致ERROR 1406: Data too long for column或直接报错ERROR 1442: Can't update table in stored function/trigger - 如果应用层也频繁更新
orders.total_amount，建议把该字段设为GENERATED ALWAYS AS（MySQL 5.7+）并移除手动维护逻辑，彻底规避冲突
PostgreSQL 里怎么写等效触发器（语法差异点）
PG 不支持直接在触发器体里写 UPDATE，必须用 EXECUTE 拼接动态 SQL，或写成触发器函数。最简方案是定义函数：
CREATE OR REPLACE FUNCTION update_order_total()
RETURNS TRIGGER AS $$
BEGIN
IF TG_OP = 'INSERT' THEN
UPDATE orders SET total_amount = total_amount + (NEW.quantity * NEW.unit_price)
WHERE id = NEW.order_id;
ELSIF TG_OP = 'UPDATE' THEN
UPDATE orders SET total_amount = total_amount - (OLD.quantity * OLD.unit_price) + (NEW.quantity * NEW.unit_price)
WHERE id = NEW.order_id;
ELSIF TG_OP = 'DELETE' THEN
UPDATE orders SET total_amount = total_amount - (OLD.quantity * OLD.unit_price)
WHERE id = OLD.order_id;
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
关键区别：OLD/NEW 是记录类型，不能直接当标量用；RETURN NEW 必须写，否则 INSERT/UPDATE 失败；PG 对事务一致性更严格，同一事务内多次触发会自动串行化，但性能略低于 MySQL 的原生 UPDATE。
容易忽略的是：PG 默认事务隔离级别是 READ COMMITTED，但如果触发器里 SELECT orders 再 UPDATE，可能读到旧快照——应显式加 SELECT ... FOR UPDATE 锁住订单行，否则高并发下仍可能算错。
