触发器内频繁查表导致性能问题，因每行变更都触发独立查询（如1000行插入即1000次SELECT），无法复用结果，索引难缓解低选择性或JOIN场景，且MySQL 5.7等版本可能引发锁冲突或报错。

为什么触发器里直接查表会导致性能问题 触发器执行时，若每次都要 SELECT ... FROM orders WHERE user_id = NEW.user_id 这类查询，而触发频率高（比如批量插入 1000 行），就会变成 1000 次独立查询。数据库无法自动复用结果，索引也未必能完全缓解——尤其当条件字段选择性低、或查询涉及多表 JOIN 时。更麻烦的是，某些数据库（如 MySQL 5.7）在触发器中对当前表（orders）做 SELECT 可能引发“表正在被修改”的锁定或错误。

用 CREATE TEMPORARY TABLE 预加载聚合结果 核心思路：不在每次触发时查，而是先一次性把高频共用数据捞出来，存进会话级临时表，后续触发都从这个临时表读。

• 临时表只在当前连接生命周期存在，不同会话互不影响，无需清理（断开即销毁）
• 必须在触发器外、业务逻辑开始前建好，比如在存储过程开头或应用层事务启动后立即执行：

  CREATE TEMPORARY TABLE tmp_user_summary AS
  SELECT user_id, COUNT(*) as order_cnt, SUM(amount) as total_spent
  FROM orders
  WHERE created_at >= DATE_SUB(NOW(), INTERVAL 7 DAY)
  GROUP BY user_id;

• 触发器内直接 SELECT order_cnt FROM tmp_user_summary WHERE user_id = NEW.user_id，毫秒级响应

注意：MySQL 中 CREATE TEMPORARY TABLE 不能在触发器内部执行，否则报错 ERROR 1314 (00000): CREATE TEMPORARY TABLE is not allowed in stored function or trigger。

如何让临时表适配触发器的上下文变量 临时表本身没有“动态绑定”，所以得靠业务逻辑配合传参：

• 不要用 NEW 或 OLD 直接进 CREATE TEMPORARY TABLE（语法不支持）
• 正确做法是：在触发器外，用应用层或存储过程把本次操作涉及的 user_id 列表提取出来，再建临时表过滤：

  CREATE TEMPORARY TABLE tmp_batch_users AS
  SELECT DISTINCT user_id FROM (
  SELECT NEW.user_id UNION SELECT OLD.user_id
  ) AS batch;

• 然后基于 tmp_batch_users 关联主表聚合，避免全表扫描

如果触发器要处理 INSERT/UPDATE/DELETE 混合场景，建议统一用 INSERT ... ON DUPLICATE KEY UPDATE 预填充临时表，而不是反复 DROP 和重建。

PostgreSQL 用户注意 ON COMMIT DROP 的陷阱 PostgreSQL 支持更灵活的临时表生命周期控制，但默认是 ON COMMIT PRESERVE ROWS。若在事务中建临时表又没显式 COMMIT，下一次相同事务内的触发器仍能读到旧数据——这容易导致脏读。

• 显式声明更安全：CREATE TEMPORARY TABLE tmp_user_stats ON COMMIT DROP AS ...
• 或者改用 WITH CTE 替代（适用于逻辑简单、数据量小的场景）：

  WITH user_stats AS (
  SELECT user_id, COUNT(*) FROM orders GROUP BY user_id
  )
  SELECT * FROM user_stats WHERE user_id = NEW.user_id;

  但 CTE 不可复用，每次触发仍执行一次子查询，仅比裸查略优。

临时表不是银弹：它把 IO 压力前移到了事务开头，且占用内存和会话资源。真正关键的，是判断“哪些数据真的会被多次读”——别为了省一次查询，强行加一层临时表。