不能直接绕过索引失效，但可通过临时表间接规避：将筛选结果存入可建索引的临时表，利用其小数据量和可控执行计划提升性能，且索引需显式创建。
临时表能绕过索引失效问题吗？
不能直接绕过，但可以间接规避。当 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不支持范围查询（<,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 写法”转移到“分步控制中间态”，真正起效的前提是清楚每一步的数据规模、分布特征和驱动表选择。漏掉任何一个，都可能让临时表变成性能黑洞。
