Using temporary 出现在执行计划中需警惕，它表示MySQL正建临时表完成查询（如DISTINCT/UNION去重），易引发全表扫描、排序及落盘，导致性能骤降。
为什么 Using temporary 出现在执行计划里就该警惕
它不是报错，但意味着 MySQL 正在内存或磁盘上建临时表来完成查询——尤其是当 DISTINCT 或 UNION 没法走索引去重时。临时表本身不慢，慢在它常伴随全表扫描、排序、多次 I/O，且容易触发 tmp_table_size 或 max_heap_table_size 限制后落盘，性能断崖式下跌。
-
Using temporary和Using filesort同时出现，基本等于“没走对索引” - 哪怕只查 10 行，只要优化器判定无法用索引完成去重，仍会建临时表
- 5.7+ 版本中，
UNION默认去重（即隐含DISTINCT），比UNION ALL多一层临时表开销
DISTINCT 怎么写才不触发临时表
核心是让去重操作能复用已有索引的有序性，避免额外排序。不是所有 DISTINCT 都能消除临时表，关键看字段是否构成索引最左前缀，且查询条件能命中该索引。
- 如果只查
SELECT DISTINCT user_id FROM orders WHERE status = 'paid'，而(status, user_id)有联合索引，大概率避免临时表；换成(user_id, status)就不行 -
DISTINCT多列时，必须所有列都在同一索引中按顺序出现，且无函数包裹（如DISTINCT UPPER(name)必走临时表） - 用
GROUP BY替代DISTINCT有时更可控，尤其配合MIN()/MAX()取关联字段，但前提是GROUP BY字段有索引
UNION 比 UNION ALL 多了什么代价
UNION 的去重逻辑本质是把两个结果集合并后做一次 DISTINCT，无论子查询本身是否已排好序。MySQL 不会智能跳过重复检查，除非你明确告诉它“不用去重”。
kashen-mysql DDLtoExcel
下载
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 即使两个
SELECT结果集天然不重叠（比如按不同时间分区查），UNION仍会建临时表合并再去重 -
UNION ALL零去重开销，结果集直接追加，适合日志归并、分表汇总等场景 - 若必须用
UNION，确保每个子查询都带ORDER BY+LIMIT且字段有索引——这能让临时表变小，但不能消除它
怎么确认改写后真没 Using temporary
别信直觉，每次调整后必须 EXPLAIN FORMAT=TREE（8.0+）或 EXPLAIN + 看 Extra 列。有些看似合理的改写，因优化器统计信息不准或参数设置，仍可能退化。
- 执行
EXPLAIN前先ANALYZE TABLE更新统计信息，否则可能误判索引可用性 -
tmp_table_size设太小（如默认 16M）会导致本可在内存完成的临时表强行落盘，此时SHOW STATUS LIKE 'Created_tmp_disk_tables'会上升 - 注意
Using temporary可能藏在子查询里——主SELECT的Extra看不到，得单独EXPLAIN子查询
临时表不是原罪，但它是索引设计或查询逻辑没对齐的信号灯。真正难的是判断“这里到底需不需要去重”，而不是一看到 Using temporary 就急着加索引或拆 SQL。
