临时表不支持自动索引，必须显式创建并更新统计信息；mysql 8.0.13+、postgresql、sql server均需在建表后手动建索引，且需analyze确保优化器正确使用。
临时表本身不支持“临时索引”这个概念——索引必须显式创建，且对临时表生效的前提是数据库版本和引擎支持。 你真正要做的，是在临时表上建真实索引，并确保它被优化器用上。
为什么CREATE INDEX ON temp_table不是可选操作
临时表默认无任何索引。哪怕只插入10万行，后续JOIN或WHERE时若没索引，优化器大概率走全表扫描——这比原查询还慢。尤其在MySQL 8.0.13+之前，CREATE TEMPORARY TABLE建的InnoDB临时表甚至不支持INDEX语法；PostgreSQL和SQL Server则要求先完成SELECT INTO TEMP再建索引。
- MySQL：必须用
CREATE TEMPORARY TABLE temp_ids (id BIGINT PRIMARY KEY)或后续CREATE INDEX idx_id ON temp_ids (id)（8.0.13+） - PostgreSQL：建表后立刻执行
CREATE INDEX ON temp_orders (user_id) - SQL Server：
CREATE CLUSTERED INDEX IX_uid ON #temp_orders (user_id)比非聚集索引更有效 - 别信“临时表自动快”——没索引的临时表，就是一张没腿的桌子
哪些字段必须加索引，取决于你怎么用它
索引不是越多越好，而是要匹配实际驱动逻辑。如果你后续用临时表去JOIN用户表，条件是ON t.user_id = u.id，那user_id就是刚需；如果还要按时间范围过滤，就该建复合索引。
- 优先建复合索引：
CREATE INDEX idx_user_time ON temp_orders (user_id, order_time)，比两个单列索引更高效 - WHERE中高选择性条件（如
status = 'paid'）应下推到INSERT INTO temp_table SELECT ... WHERE阶段，而不是塞进大结果集再筛 - 字符串ID字段别盲目加索引：MySQL对
VARCHAR(2000)建索引会截断，默认只索引前767字节；PostgreSQL需用text_pattern_ops处理前缀匹配
建完索引后，优化器可能还在瞎猜
MySQL和PostgreSQL不会自动更新临时表的统计信息。刚INSERT完50万行，EXPLAIN仍显示“rows=1”，导致优化器误判驱动顺序，甚至放弃使用你刚建的索引。
- MySQL：插入完成后立刻执行
ANALYZE TABLE temp_ids - PostgreSQL：执行
ANALYZE temp_ids - 云数据库（如阿里云RDS）部分版本禁用
ANALYZE，此时改用OPTIMIZE TABLE temp_ids（仅InnoDB有效） - 别依赖
innodb_stats_auto_update=ON——它对临时表基本不生效
JOIN替代IN时，DISTINCT和驱动顺序容易翻车
原WHERE id IN (SELECT id FROM ...)天然去重；但改成JOIN temp_ids后，若原子查询有重复ID或一对多关系，结果会膨胀，COUNT失真，内存占用翻倍。
- 如果业务只要“是否存在”，用
SELECT DISTINCT u.* FROM users u JOIN temp_ids t ON u.id = t.id - 如果要保留明细（比如用户+订单），去掉
DISTINCT，但得确认应用层能否容忍重复行 - 执行前跑
EXPLAIN FORMAT=TREE，确认驱动表是temp_ids（小表）；若显示大表被驱动，说明统计不准，不是加STRAIGHT_JOIN就能解决的
最常被忽略的一点：临时表数据量超过500万行时，重建开销本身就会成为瓶颈。这时“建索引”已不够用，得考虑分区临时表，或直接落地为带索引的staging_*普通表——否则每次DROP再CREATE都在拖慢整体流程。
