加了索引仍出现Using temporary，根本原因不是索引缺失，而是索引未匹配查询逻辑：GROUP BY字段不在索引最左前缀、函数包裹导致索引失效、WHERE与分组字段顺序错配、子查询中隐含聚合等，均迫使MySQL放弃流式分组而创建临时表。
为什么加了索引 still 出现 Using temporary
不是索引没建，而是索引没对上查询逻辑。MySQL 的 GROUP BY、DISTINCT 或 UNION 要复用索引的物理有序性，必须满足字段顺序和覆盖条件。
-
GROUP BY a却只建了INDEX(b, a)→ 无法利用，a 不在最左前缀 -
SELECT DISTINCT UPPER(name)→ 函数包裹直接让索引失效，必走临时表 -
WHERE status = 'paid' GROUP BY user_id，但索引是(user_id, status)→ 过滤字段不在前，只能用于回表，分组仍需临时表 - 子查询里有
GROUP BY，主查询EXPLAIN看不到Using temporary，得单独EXPLAIN子查询
怎么建索引才能真正绕过临时表
核心是让 MySQL 能“流式分组”：按索引顺序扫描，边读边聚合，不缓存中间结果。
- 纯
GROUP BY a→ 必须有INDEX(a)或INDEX(a, amount)（后者可覆盖聚合字段） -
WHERE c = 1 GROUP BY a, b→ 最优索引是INDEX(c, a, b)，顺序不能颠倒 -
SELECT a, COUNT(*) FROM t WHERE d > 10 GROUP BY a ORDER BY NULL→ 加ORDER BY NULL可避免隐式排序触发Using filesort - 高基数字段如
user_id直接GROUP BY→ 即使索引存在，分组桶太多也易落盘；应先降维（如按地区聚合）或改用APPROX_COUNT_DISTINCT()
tmp_table_size 和 max_heap_table_size 怎么调才有效
这两个参数决定内存临时表上限，但只起兜底作用——设错、设单、不监控，等于白调。
- 必须同步设置：
SET SESSION tmp_table_size = 67108864和SET SESSION max_heap_table_size = 67108864 - 默认值常为 16MB（
16777216），几万行聚合就可能撑爆；生产建议设为 64MB–256MB - 调完必须看监控：
SHOW STATUS LIKE 'Created_tmp_disk_tables'/Created_tmp_tables比值持续 > 5% 就说明还在落盘 - 该设置对已建立连接无效，新连接才生效；全局生效需写入配置并重启或用
SET PERSIST
哪些 SQL 写法会悄悄触发 Using temporary
有些语句表面简单，实则强制建临时表，且容易被忽略。
-
UNION默认等价于UNION DISTINCT→ 即使两个子查询结果天然不重叠，也会合并后去重；优先用UNION ALL -
SELECT DISTINCT a, b FROM t ORDER BY c→c与分组字段无关，MySQL 必须先去重再排序，绕不开临时表 -
SELECT user_id, viewed_user_sex FROM t GROUP BY viewed_user_age→ 违反 SQL 标准（非分组字段未聚合），MySQL 强制兜底用临时表 - 没跑过
ANALYZE TABLE就执行EXPLAIN→ 统计信息陈旧，优化器可能误判索引可用性，导致本可走索引的查询退化
Using temporary 的关键，从来不是把 tmp_table_size 设到 1GB，而是让查询逻辑和索引结构严丝合缝——字段顺序错一位，函数包一层，WHERE 条件写偏一点，都足以让优化器放弃流式处理，转身建临时表。 
