临时表更稳因其是物理表，可建索引、可复用、可分步验证；而cte是逻辑视图，不物化、不能建索引、多次引用可能重算，且与临时表作用域不互通。
临时表不是“加个TEMPORARY就能提速”，它真正起效的前提是：中间结果被多次引用、原查询因缺乏索引反复全表扫描、或优化器误估基数导致执行计划崩坏——否则硬拆反而更慢。
为什么CREATE TEMPORARY TABLE比子查询或CTE更稳？
MySQL 的 WITH CTE 在 8.0+ 支持，但它是逻辑视图，不物化、不能建索引、每次引用都可能重算；而 CREATE TEMPORARY TABLE 是物理表，可加索引、可复用、可分步验证。
- CTE 里写
SELECT * FROM temp_users会报错：Table 'temp_users' doesn't exist—— 因为 CTE 和临时表作用域不互通 - 嵌套 3 层子查询时，EXPLAIN 显示
type=ALL且rows是原始表量级，说明优化器没拿到过滤后的真实行数 - 临时表一旦建好，后续所有
JOIN或WHERE都能走索引，而 CTE 即使加MATERIALIZED（MySQL 不支持该关键字）也无法绕过无索引限制
建临时表时字段和引擎怎么选才不翻车？
最常踩的坑是用 CREATE TEMPORARY TABLE tmp AS SELECT ...，看似省事，实则埋雷：字段类型被隐式截断、无主键、无索引、字符集丢失。
- 显式定义结构：用
CREATE TEMPORARY TABLE tmp (id BIGINT PRIMARY KEY, city VARCHAR(32), INDEX idx_city (city)) ENGINE=MEMORY - 数据量预估超 50 万行？别硬撑
ENGINE=MEMORY，改用ENGINE=InnoDB，否则触发磁盘落盘（MyISAM 临时文件），I/O 反而更重 - 含中文或 emoji？必须声明
CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，否则 JOIN 时隐式转换，索引失效 - 禁用
TEXT/BLOB字段——只要出现，MySQL 就强制退化为磁盘表，哪怕只存 1 行
连接池环境下临时表为何总报“Table already exists”？
应用用了 HikariCP、Druid 等连接池，物理连接被复用，CREATE TEMPORARY TABLE 建的表不会随 HTTP 请求结束而销毁，下次同名建表就撞车。
- 每次使用前加
DROP TEMPORARY TABLE IF EXISTS tmp_calc（注意是TEMPORARY TABLE，不是TABLE） - 不要依赖“连接断开自动删”——连接池让这个假设彻底失效
- 存储过程里避免无条件
CREATE，固定流程应为：DROP→CREATE→INSERT - 若需事务级隔离，可用
CREATE TEMPORARY TABLE ... ON COMMIT DROP（MySQL 8.0.13+ 支持）
索引和更新操作怎么配才真提速？
建完表不加索引，等于白建。临时表默认无任何索引，JOIN 或 WHERE 仍会全表扫。
- 建表后立刻执行
CREATE INDEX idx_user_id ON tmp_orders (user_id)，别等EXPLAIN报Using temporary再补 - 批量更新用
UPDATE t1 INNER JOIN tmp_calc ON t1.id = tmp_calc.id SET ...，禁用LEFT JOIN，否则没匹配上的行会被设为NULL - 如果中间结果要多次用于不同条件过滤，优先按高频
WHERE字段建复合索引，比如INDEX idx_status_time (status, created_at) -
tmp_table_size和max_heap_table_size必须查：二者取小值才是内存临时表上限，用SHOW VARIABLES LIKE 'tmp_table_size'确认
真正难的不是那句 CREATE TEMPORARY TABLE，而是想清楚：中间结果是否真的被复用、字段长度有没有压到最小、索引是否覆盖了后续所有查询路径、连接生命周期有没有被连接池悄悄延长——漏掉任意一环，临时表就从加速器变成性能黑洞。
