在写SQL时，我们常需要依据计算后的列来连接多张表，例如把一个表里的时间戳转成日期字符串，再和另一张按天汇总的表关联。这类写法在关联条件里直接调用函数，数据库通常难以利用索引，只能做全表扫描再加计算，数据量一大就非常慢。把计算逻辑物化到临时表，是常见的一种优化思路。
为什么计算列关联会变慢
当连接条件写成 table_a.col + 1 = table_b.col 或 date_format(table_a.create_time, '%Y-%m-%d') = table_b.day 时，优化器往往不能在 table_a 的计算列上使用普通索引。它会先算出每一行的计算值，再拿去匹配，代价随数据量线性增长。
将计算逻辑物化到临时表的基本做法
我们可以把需要参与关联的计算结果提前算出来，写入临时表，再让临时表和别的表做干净列的连接。
-- 创建临时表存放物化后的计算列 CREATE TEMPORARY TABLE tmp_user_day AS SELECT user_id, DATE_FORMAT(create_time, '%Y-%m-%d') AS create_day FROM orders; -- 在临时表的计算列上建索引 ALTER TABLE tmp_user_day ADD INDEX idx_create_day (create_day); -- 用干净列关联，避免函数在连接条件中出现 SELECT u.user_name, d.create_day, COUNT(*) AS order_cnt FROM tmp_user_day d JOIN users u ON u.user_id = d.user_id JOIN day_summary s ON s.day = d.create_day GROUP BY u.user_name, d.create_day;
适用场景
- 原表数据量大，且计算逻辑较为复杂或重复参与多次关联
- 同一查询中多次用到相同的计算列
- 数据库版本对计算列索引支持较弱
需要注意的问题
物化到临时表不是万能的。首先，临时表会占用额外空间，并且如果源表数据在事务中变化，临时表不会自动同步。其次，建临时表和写数据的步骤本身有开销，小数据量时可能反而更慢。你可以参考下面的简单对比：
| 方式 | 小数据量 | 大数据量 |
|---|---|---|
| 直接计算列关联 | 简单直接，够用 | 易全表扫描，慢 |
| 临时表物化 | 额外开销，不划算 | 索引可用，明显更快 |
更轻量的替代方案
如果数据库支持，也可以直接在建表时加生成列并建索引，例如 MySQL 的 STORED 生成列，这样不用手动维护临时表：
ALTER TABLE orders ADD COLUMN create_day CHAR(10) AS (DATE_FORMAT(create_time, '%Y-%m-%d')) STORED, ADD INDEX idx_create_day (create_day);
总结来说，将计算逻辑物化到临时表在复杂关联和大批量数据下是可行且有效的优化手段，但要结合数据量、一致性和维护成本来判断是否采用。