mysql内部临时表由优化器自动创建，开销主因内存不足落盘而非建表本身；触发场景包括未索引的group by/order by、distinct多列、派生表未物化、union去重排序及窗口函数帧计算等。
MySQL 临时表在复杂查询中既是“幕后推手”，也是性能关键变量——它既可能被优化器自动创建（内部临时表），也可能由你主动建表（用户临时表）。真正影响性能的，往往不是“有没有用”，而是“怎么用、何时用、用对没用对”。
哪些查询会悄悄生成内部临时表？
这类表完全由 MySQL 自动管理，你无法 SELECT 查看，但能从 EXPLAIN 或状态变量中识别。常见触发场景包括：
-
GROUP BY 无索引字段：比如
SELECT city, COUNT(*) FROM users GROUP BY city，若city没索引，MySQL 必须建临时表暂存分组结果 -
DISTINCT + 排序混合：如
SELECT DISTINCT name FROM users ORDER BY created_at，去重和排序逻辑冲突，需中间落表 -
UNION（非 ALL）：合并结果后必须去重，临时表是必经之路；而
UNION ALL通常跳过这步 - 多表 JOIN 且关联字段无索引：优化器无法走嵌套循环或哈希连接时，会把驱动表结果暂存为临时表再逐行匹配
-
子查询出现在 FROM 子句（派生表）：例如
SELECT * FROM (SELECT user_id, SUM(amount) FROM orders GROUP BY user_id) t WHERE t.sum > 1000，括号内就是隐式临时表
手动建临时表的正确姿势
当你需要复用中间结果、拆解逻辑或绕过语法限制（比如 UPDATE 子查询报错 1093），显式建临时表更可控。但光 CREATE 不够，关键在三步闭环：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
建表阶段就定好结构：避免用
CREATE TEMPORARY TABLE AS SELECT省事，它易推导出 TEXT/BLOB 类型导致磁盘落表；推荐先CREATE TEMPORARY TABLE t (id BIGINT PRIMARY KEY, status TINYINT)，再INSERT INTO t SELECT ... -
写入后立即加索引：临时表默认无任何索引。若后续要 JOIN 或 WHERE 过滤，必须在 INSERT 完成后执行
CREATE INDEX idx_id ON t(id)；别等查询时报慢才补 -
用完即删，尤其在连接池环境：临时表生命周期绑定物理连接，不是会话或事务。连接池复用时残留表会引发 “Table 'xxx' already exists” 错误，务必加
DROP TEMPORARY TABLE IF EXISTS t
让临时表 stays in memory 的硬核配置
内存临时表比磁盘快一个数量级，但 MySQL 默认阈值极保守（通常 16MB），稍大点的中间结果就强制落盘。关键不在调单个参数，而在协同控制：
-
tmp_table_size 和 max_heap_table_size 必须设为相同值，例如都设为
134217728（128MB）；取小值生效，只改一个等于白改 - 估算中间数据大小再设值：一行约 40 字节（INT + VARCHAR(20) + DATETIME），10 万行 ≈ 4MB，建议留 2–3 倍余量；线上并发高时注意总内存占用（如 100 连接 × 128MB = 12.8GB）
-
监控是否真在用内存表：查
SHOW STATUS LIKE 'Created_tmp_disk_tables'，数值持续上涨说明频繁落盘；配合SHOW PROCESSLIST看是否卡在 “Creating tmp table”
临时表不是银弹：什么情况该慎用？
它解决的是“可复用中间结果”和“绕过语法限制”问题，不是万能加速器：
- 单次小结果集查询：比如只查几十行，建表+索引+删除的开销可能超过直接查原表
-
更新依据是模糊条件：如
WHERE name LIKE '%abc%'，临时表无法建立高效索引，JOIN 仍退化为全表扫描 - 数据源无法一次性获取：比如来自 API 流式分页，无法构建完整临时表，应改用 ID 分段或游标方案
- 目标表关联字段无索引且不可加：临时表有索引没用，UPDATE 或 JOIN 仍扫全表
