物化临时表慢因无索引导致全表扫描；EXPLAIN中select_type=MATERIALIZED且Extra含Using temporary即为瓶颈，小结果集时直接JOIN更高效。
物化临时表为什么慢？关键看Extra和select_type
MySQL 8.0+ 默认对非相关子查询尝试物化，但物化表本身不建索引——哪怕你子查询里查的是 SELECT id FROM users WHERE status = 'active'，结果被物化后，外层 IN 或 JOIN 查找仍要全表扫描这张临时表。EXPLAIN 中若看到 select_type = MATERIALIZED 且 Extra 含 Using temporary，基本可确认是这个瓶颈。
强制禁用物化比默认物化更快的场景
当子查询结果小（
SELECT * FROM orders
WHERE user_id IN (/*+ NO_MATERIALIZATION() */
SELECT user_id FROM blacklist WHERE expire_time > NOW());
改写后观察 EXPLAIN：select_type 应从 MATERIALIZED 变为 SUBQUERY，Extra 出现 Using index condition 或 Using join buffer (hash join) 才算生效。
- 该 hint 在 MySQL 5.7 及更早版本无效，别白试
- 如果子查询含
LIMIT、GROUP BY或外部列引用（如t1.id = t2.parent_id），hint 也无效，物化本就不会触发 - 禁用物化后若变慢，说明原物化其实合理——此时应检查
blacklist.user_id是否有索引，而非硬扛
人工创建带索引的临时表替代物化
当优化器反复不按预期物化，或子查询逻辑复杂（含窗口函数、多层嵌套），最可控的方式是手动物化并加索引：
CREATE TEMPORARY TABLE tmp_blacklist AS SELECT DISTINCT user_id FROM blacklist WHERE expire_time > NOW(); ALTER TABLE tmp_blacklist ADD PRIMARY KEY (user_id); SELECT o.* FROM orders o INNER JOIN tmp_blacklist t ON o.user_id = t.user_id;
注意点：
-
TEMPORARY TABLE对当前会话可见，无需担心并发冲突 - 必须显式
ADD PRIMARY KEY或ADD INDEX，否则仍是无索引扫描 - 如果子查询结果含 NULL，
INNER JOIN会自动过滤掉，语义上等价于IN（NULL 不匹配），无需额外处理
物化不是银弹：小结果集 + 好索引时，直接 JOIN 更稳
真正容易被忽略的是：物化开销（内存分配、数据拷贝、临时表管理）在结果集很小时反而拖累性能。比如 SELECT * FROM users WHERE id IN (SELECT id FROM roles WHERE name = 'admin')，若 roles.name 有索引且结果仅几行，直接改写为 JOIN 最干脆：
SELECT u.* FROM users u INNER JOIN roles r ON u.id = r.id AND r.name = 'admin';
这种写法绕过所有物化逻辑，全程走索引查找，执行计划中 type 通常为 eq_ref 或 ref，rows 预估精准，且兼容 MySQL 5.7+ 所有版本。
物化是否启用，取决于子查询是否“只读”且“无外部引用”，而人眼判断远比优化器可靠——遇到慢子查询，先看 EXPLAIN，再决定是 hint、手动物化，还是直接 JOIN，别迷信“默认物化就一定好”。
