触发器中写join会导致单条写入延迟激增数十倍，因其行级同步执行、无法优化驱动顺序、无查询缓存，易退化为block nested-loop join；应改用异步队列、物化预计算或应用层校验替代。
触发器里写 JOIN 会让单条写入变慢几十倍
因为触发器是行级同步执行的，每插入或更新一行，就完整跑一遍里面的 SQL。比如在 AFTER INSERT 里写 SELECT SUM(amount) FROM order WHERE user_id = NEW.user_id，那每下一单就触发一次关联查询——不是“慢一点”，而是单条延迟从 0.5ms 拉到 20ms+；1000 QPS 场景下，数据库连接池很快就会被占满。
更关键的是，这类 JOIN 在触发器中无法被优化器重排驱动表顺序，也没有查询缓存，几乎必然退化为 Block Nested-Loop Join，且不支持索引下推。哪怕关联字段有索引，MySQL 也不会在触发器上下文中做任何优化。
- 每行变更都重复执行相同 JOIN，IO 和 CPU 开销线性放大
- 多表 JOIN + 聚合（如
COUNT()、SUM()）会让EXPLAIN失效，实际执行计划不可预测 - PostgreSQL 中调用含
PERFORM或SELECT的函数，等于又套了一层不可见 JOIN
常见但危险的触发器 JOIN 场景
这些写法看着合理，实则在高并发下迅速成为瓶颈：
-
SELECT points FROM user_points WHERE user_id = NEW.user_id：用户积分表不大？但每单都查一次，索引查找频次爆炸，锁竞争激增 -
SELECT name FROM staff WHERE id = NEW.operator_id：看似只查主键，但每条日志都触发一次回表，IO 放大 N 倍 -
SELECT status FROM product WHERE id = NEW.product_id：若product表的 WHERE 条件没走索引（比如含OR或LIKE '%xxx'），直接全表扫
它们在应用层调用一次是常态，在触发器里重复执行就是反模式——本质是把应用层的“一次查”错配成“每行查”。
替代方案比硬扛 JOIN 更有效
真正要解决的不是“怎么让 JOIN 快一点”，而是“能不能不在这儿查”。优先级从高到低：
- 能用
CHECK约束或应用层校验的，就别放触发器里 - 必须查外部状态？改用异步：触发器只写轻量队列表（如
INSERT INTO queue_table (table_name, row_id) VALUES ('orders', NEW.id)），后台任务批量处理 - 需要实时聚合？提前物化：用定时任务维护
user_daily_summary表，触发器只读这张预计算表 - MySQL 8.0+ 可考虑用
INSERT ... ON DUPLICATE KEY UPDATE替代“先查再更”的逻辑
注意：FOR EACH ROW 是默认行为，批量插入时会被放大 N 倍；PostgreSQL 可用 WHEN (pg_trigger_depth() = 0) 控制只触发一次，但 MySQL 没这个能力，只能靠设计规避。
容易被忽略的隐性成本
很多人只盯着查询耗时，却漏掉三个更隐蔽的问题：
- 触发器内 JOIN 会延长事务持有锁的时间——哪怕只查不改，也会阻塞其他连接对源表的读写
- MySQL 对
OLD/NEW访问BLOB/TEXT字段时，会隐式创建磁盘临时表，开销远超预期 - SQL Server 中触发器运行在主事务上下文，一旦 JOIN 超时或失败，整个业务事务直接回滚，错误定位困难
最麻烦的是：这类问题往往在压测或上线后才暴露，而触发器本身又难调试、难 mock、难单元测试——等发现时，系统可能已长期处于亚健康状态。
