不能直接用new.total_amount = sum(...)，因new是单行上下文而sum为聚合函数，须通过select...into配合coalesce赋值；update触发器必须用before；并发下需select...for update加锁或改用视图/异步方案。
触发器里不能直接用 NEW.total_amount = SUM(...)？
不能。MySQL 触发器中 NEW 是单行上下文，SUM() 是聚合函数，必须配合 SELECT ... INTO 才能赋值。常见错误是写成 SET NEW.total_amount = SUM(detail.price * detail.qty);，直接报错 “Invalid use of group function”。
正确做法是先查出明细行的合计值，再赋给 NEW.total_amount：
SELECT COALESCE(SUM(price * qty), 0) INTO @total FROM order_detail WHERE order_id = NEW.id;
COALESCE 防止 NULL 导致整字段变 NULL；@total 是用户变量，仅用于临时中转（不能直接 SET NEW.total_amount = @total，需显式赋值）。
UPDATE 触发器该用 BEFORE 还是 AFTER？
必须用 BEFORE UPDATE。因为你要修改即将写入的 NEW.total_amount 值，而 AFTER 触发时数据已落库，NEW 不可写，且再改也没意义。
注意：如果业务逻辑要求“总金额只读、禁止手动改”，就在触发器里加校验：
- 检查
OLD.total_amount != NEW.total_amount，然后SET NEW.total_amount = OLD.total_amount强制回滚修改 - 或直接
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'total_amount is auto-calculated';
订单主表更新时，如何确保关联明细没被并发删改？
触发器本身不加锁，但计算依赖 order_detail 表。如果在触发器执行期间，另一事务删了某条明细，会导致 total_amount 计算偏小 —— 这是典型幻读风险。
解决办法只有两个：
- 把订单主表和明细表的更新包装进同一事务，并在触发器前用
SELECT ... FOR UPDATE锁住相关明细行（例如：SELECT 1 FROM order_detail WHERE order_id = NEW.id FOR UPDATE;） - 放弃触发器，改用应用层统一走存储过程更新，由上层控制事务边界和锁范围
别指望靠 READ COMMITTED 隔离级别躲开这个问题 —— 它对触发器内查询无效。
触发器性能差，有没有更稳的替代方案？
有。触发器在高并发更新场景下容易成为瓶颈，尤其当 order_detail 行数多、索引缺失时，每次更新都要全表扫描明细。
推荐组合方案：
- 主表去掉
total_amount字段，改用视图实时计算：CREATE VIEW order_with_total AS SELECT o.*, COALESCE(d.total, 0) AS total_amount FROM orders o LEFT JOIN (SELECT order_id, SUM(price * qty) AS total FROM order_detail GROUP BY order_id) d ON o.id = d.order_id; - 如需写入性能，用定时任务（比如每分钟）异步刷新缓存表，而非强一致性实时计算
真正难的不是怎么写触发器，而是想清楚：这个“自动计算”到底要多准、多快、多稳 —— 三者不可兼得，得选一个妥协点。
