正确做法是在BEFORE INSERT触发器中，用子查询从price_history表查出对应item_id的最新price（按valid_from降序取第一条），赋值给NEW.unit_price；MySQL 8.0+支持ORDER BY ... DESC LIMIT 1，PostgreSQL更灵活支持窗口函数；须建(item_id, valid_from)联合索引并过滤NULL/未来时间以防错。
INSERT 时用触发器查最新 price，但别直接 UPDATE 原表
触发器里不能对「正在被 INSERT 的同一张表」做 SELECT（某些数据库会报 mutating table 错误），更不能在 BEFORE INSERT 里 UPDATE 自己。正确做法是：在 BEFORE INSERT 触发器中，用子查询从关联表（如 price_history）捞出对应商品的最新价格，然后赋值给新行的 unit_price 字段。
假设你有两张表：
orders (order_id, item_id, unit_price, qty) price_history (item_id, price, valid_from)
目标是插入 orders 时不填 unit_price，由触发器自动补上该 item_id 在 price_history 中 valid_from 最大的那条价格。
关键点：
-
BEFORE INSERT触发器可安全修改:NEW.unit_price - 查最新价必须用确定性子查询，例如
(SELECT price FROM price_history p2 WHERE p2.item_id = :NEW.item_id ORDER BY valid_from DESC LIMIT 1) - 如果某
item_id在price_history中无记录，子查询返回 NULL —— 你需要决定是否允许（加COALESCE(..., 0)或抛异常）
MySQL / PostgreSQL 触发器写法差异要点
MySQL 和 PostgreSQL 都支持 BEFORE INSERT 触发器，但语法和限制不同：
- MySQL：子查询里不能直接用
LIMIT，得套一层(SELECT * FROM (SELECT ...) AS t LIMIT 1)，或改用ORDER BY ... DESC LIMIT 1（8.0+ 支持） - PostgreSQL：可直接用
(SELECT price FROM price_history WHERE item_id = NEW.item_id ORDER BY valid_from DESC LIMIT 1)，且支持窗口函数（如ROW_NUMBER() OVER (PARTITION BY item_id ORDER BY valid_from DESC)），更灵活 - 两者都不允许在触发器里开启事务或调用存储过程修改其他行（除非显式声明为
DEFINER或绕过限制）
为什么不用外键 + 默认值或计算列？
因为价格是随时间变化的业务事实，不是静态属性。外键只保证 item_id 存在，不解决「取哪条 price」的问题；默认值（DEFAULT）只能是常量或简单函数（如 NOW()），无法跨表查最新记录；计算列（Generated Column）在 MySQL/PG 中也不支持子查询，所以触发器仍是主流解法。
替代思路（不推荐但可了解）：
- 应用层预查：插入前先
SELECT price FROM price_history WHERE item_id = ? ORDER BY valid_from DESC LIMIT 1，再拼 INSERT 语句 —— 多一次 round-trip，且存在时间差风险（价格刚好在两次查询间更新） - 物化视图或冗余字段：在
items表加current_price并用定时任务刷新 —— 数据滞后，且需额外维护一致性
容易忽略的性能与边界坑
触发器看着方便，但上线后容易暴雷：
- 没给
price_history(item_id, valid_from)建联合索引 → 每次 INSERT 都全表扫price_history，插入变慢十倍 -
valid_from允许 NULL 或未来时间 →ORDER BY valid_from DESC可能把无效记录排最前，应加WHERE valid_from - 并发插入同个
item_id时，触发器各自查各自的价格，没问题；但如果价格本身也在高频更新，而你又依赖「最新一条」逻辑，就得确认业务是否接受「插入时刻看到的价格」而非「订单生成时刻的价格」
真正难的不是写触发器，而是定义清楚「最新」的业务含义：是按时间戳最大？还是按生效日期+状态字段？有没有历史价格作废机制？这些没对齐，代码写得再顺也埋雷。
