临时表能绕过索引失效问题吗？
不能直接绕过，但可以间接规避。当
WHERE条件或
JOIN逻辑导致主表索引无法使用（比如函数包裹字段、隐式类型转换、
OR多条件混合），把筛选后的中间结果存入临时表，再对临时表做后续操作，往往能让优化器重新选择高效路径。
关键点在于：临时表本身可建索引，且数据量通常远小于原表，查询计划更可控。
临时表默认使用MEMORY引擎（除非显式指定
ENGINE=InnoDB），不支持 BLOB/TEXT 类型，也不支持全文索引
CREATE TEMPORARY TABLE只对当前会话可见，断开连接自动销毁，无需手动
DROP如果中间结果含大量文本或需事务支持，必须用
ENGINE=InnoDB，否则插入失败或丢失数据
什么时候该用 SELECT INTO TEMPORARY TABLE 而不是子查询？
当子查询被重复引用 ≥2 次，或子查询本身已含复杂聚合/窗口函数/多层嵌套时，MySQL 5.7+ 仍可能多次执行该子查询（尤其在
FROM子句中作为派生表），而临时表只计算一次。
典型场景：
JOIN多张大表前，先用临时表固化一个高过滤率的结果集。
CREATE TEMPORARY TABLE tmp_active_users ENGINE=InnoDB AS SELECT user_id, last_login FROM users WHERE status = 'active' AND last_login > DATE_SUB(NOW(), INTERVAL 30 DAY); CREATE INDEX idx_user_id ON tmp_active_users (user_id);避免在
AS后直接加
ORDER BY或
LIMIT——它们在创建阶段无效，仅影响结果集顺序，不改变物理存储 如果原查询含
GROUP BY，临时表会丢失分组语义，需确认是否需要保留聚合字段 临时表的列名继承自
SELECT列别名（如有），否则为表达式文本，易产生不可读名称如
count(*)
临时表上的索引真的有用吗？
有用，但仅限于显式创建的索引。MySQL 不会为
CREATE TABLE ... AS SELECT自动生成任何索引，即使源表有对应索引。
常见误判：以为 “从带索引的表查出来的临时表，自然也快” —— 实际上临时表是全新结构，无索引即全表扫描。
建索引必须在INSERT或
CREATE ... AS SELECT完成后单独执行，不能合并到一条语句里
MEMORY引擎只支持
HASH（默认）和
B-TREE索引，
HASH不支持范围查询（
, <code>BETWEEN），务必用
USING BTREE显式声明 对小数据量（
为什么用了临时表反而变慢了？
最常见原因是磁盘落地：当
MEMORY临时表超出
tmp_table_size和
max_heap_table_size中的较小值时，MySQL 自动转为磁盘临时表（
MyISAM或
InnoDB），I/O 开销陡增。
可通过
SHOW STATUS LIKE 'Created_tmp%';观察
Created_tmp_disk_tables是否明显增长。 检查当前限制：
SELECT @@tmp_table_size, @@max_heap_table_size;若确认需大临时表，应调高两者至相近值（如都设为 256M），但注意全局内存压力 避免在临时表中存储冗余字段——只保留后续 SQL 真正需要的列，减少体积和排序开销 联结临时表时，确保关联字段类型完全一致（包括字符集、是否为
NOT NULL），否则触发隐式转换，索引失效
临时表不是银弹，它把优化焦点从“单条 SQL 写法”转移到“分步控制中间态”，真正起效的前提是清楚每一步的数据规模、分布特征和驱动表选择。漏掉任何一个，都可能让临时表变成性能黑洞。
