必须放在订单明细表（order_items）上，因订单总金额是明细行聚合结果，需通过AFTER INSERT/UPDATE/DELETE触发器实时响应每一行变动，避免仅监听订单表导致的更新滞后或遗漏。
触发器该放在订单表还是订单明细表？
必须放在订单明细表（order_items）上。订单总金额是明细行的聚合结果，任何一行增删改都会影响总额；如果只在订单表上设触发器，无法感知明细变化，更新必然滞后或遗漏。
常见错误是试图在 orders 表上用 BEFORE UPDATE 去“重新计算”，这既不实时也不可靠——因为没监听明细变动源头。
-
AFTER INSERT、AFTER DELETE、AFTER UPDATE都要覆盖，缺一不可 - UPDATE 场景需判断
quantity或price是否真被修改，避免无谓更新（可用OLD.quantity != NEW.quantity判断） - 触发器内禁止对本表再做 DML 操作，否则会报错
Can't update table 'order_items' in stored function/trigger
如何安全地更新关联订单的 total_amount 字段？
不能直接写 UPDATE orders SET total_amount = ... WHERE id = NEW.order_id —— 这在高并发下可能引发死锁，尤其当多个明细行同时更新同一订单时。
更稳妥的做法是用单条原子更新，基于当前明细重算总额：
UPDATE orders o
JOIN (
SELECT order_id, COALESCE(SUM(quantity * price), 0) AS new_total
FROM order_items
WHERE order_id = NEW.order_id
GROUP BY order_id
) t ON o.id = t.order_id
SET o.total_amount = t.new_total;注意点：
-
COALESCE防止明细为空时SUM返回NULL，导致订单总金额变NULL - 子查询必须带
GROUP BY，否则 MySQL 8.0+ 会报错（严格模式下不允许非聚合列裸出现在 SELECT 中） - 如果订单表有
updated_at字段，建议在此处一并更新，保持时间戳同步
触发器里能调用存储函数吗？会影响性能吗？
可以，但不推荐。比如把求和逻辑抽成函数 calc_order_total(order_id)，看似清晰，实则埋坑：
- 每次触发都调用函数，函数内部再查一遍
order_items，IO 放大，尤其订单明细多时延迟明显 - MySQL 函数无法在触发器中修改数据（
READS SQL DATA是默认限制），若后续想扩展逻辑（如加折扣计算），立刻卡住 - 调试困难：错误堆栈只显示触发器名，不显示函数内部哪一行出错
真正需要复用时，应优先考虑视图（如 order_summary）或应用层缓存，而不是塞进触发器。
为什么 UPDATE 触发器里要区分 OLD 和 NEW？
因为一次更新可能只改了数量没改价格，或反之。若不判断，哪怕只是改了个无关字段（如 note），也会触发全额重算，白白消耗资源。
正确写法示例（在 AFTER UPDATE 触发器中）：
IF OLD.quantity != NEW.quantity OR OLD.price != NEW.price THEN -- 执行上面的 UPDATE orders ... 聚合逻辑 END IF;
容易忽略的边界：
-
NULL参与比较永远返回FALSE，所以要用NOT (OLD.quantity NEW.quantity)或先IFNULL处理 - 浮点数价格字段（
DECIMAL更好）若用!=比较，可能因精度丢失误判，务必统一用DECIMAL(10,2) - 订单状态为“已支付”后，理论上不应再允许修改明细——这个业务约束得在应用层或外键/检查约束里做，触发器管不了
触发器不是银弹。它解决的是“数据一致性”的最后一道防线，但没法替代应用层的校验、事务边界设计和幂等控制。上线前务必在测试库模拟并发插入/更新，观察锁等待和执行耗时。
