避免内部临时表过大的核心是让mysql不用临时表或仅在内存中完成分组/排序；explain出现using temporary即需干预，尤其叠加using filesort时必然涉及磁盘操作。
直接结论：避免内部临时表过大的核心不是调大 tmp_table_size，而是让 MySQL 根本不用临时表，或至少让它只在内存中完成分组/排序。
EXPLAIN 出现 Using temporary 就必须干预
这不是“可能慢”，是明确信号：MySQL 已放弃索引加速，转而把中间结果全拉进临时结构里处理。尤其当 Extra 同时出现 Using temporary 和 Using filesort，基本等于告诉你要查磁盘了。
- GROUP BY + ORDER BY 字段不共用同一联合索引 → 必然触发临时表
- SELECT 中包含非 GROUP BY 的非聚合字段（如
SELECT user_id, name, COUNT(*)）→ 即使有索引也会退化 - WHERE 条件用了函数（
WHERE DATE(created_at) = '2024-01-01'）→ 索引失效，数据先全扫再分组 - JOIN 后再 GROUP BY，且驱动表没过滤好 → 中间结果集膨胀，临时表尺寸失控
GROUP BY 必须走覆盖索引，且字段顺序要严丝合缝
MySQL 无法用两个索引分别服务 GROUP BY 和 ORDER BY；它只认一个联合索引的前缀匹配和连续列顺序。
- 写法：
SELECT status, COUNT(*) FROM orders WHERE created_at >= '2025-01-01' GROUP BY status ORDER BY COUNT(*) DESC - 对应索引必须是：
ALTER TABLE orders ADD INDEX idx_created_status_cnt (created_at, status)—— 注意：过滤列created_at必须放最左，status紧跟其后，才能让 GROUP BY 直接走索引扫描，跳过临时表 - 如果还要按
COUNT(*)排序，且数据量大，加SQL_BIG_RESULT提示反而更稳：SELECT SQL_BIG_RESULT status, COUNT(*) ...，它会主动绕开内存临时表，改用更稳定的磁盘哈希分组（但前提是索引已到位） - 别建
(status, created_at)这种“看起来对”的索引——WHERE 用created_at，GROUP BY 用status，前导列不匹配，照样全表扫
DISTINCT 和 GROUP BY 别混用，优先用 GROUP BY + 覆盖索引
业务上需要“去重”时，DISTINCT 看似简洁，但优化器对它的索引利用远不如 GROUP BY 积极。尤其当字段组合有高基数（比如邮箱+用户名），更容易触发落盘。
- 错误写法：
SELECT DISTINCT email, username FROM users WHERE city = 'Shanghai'，若email或username无索引 → 先取全部匹配行，再内存去重 → 临时表暴涨 - 正确路径：
SELECT email, username FROM users WHERE city = 'Shanghai' GROUP BY email, username，并建覆盖索引：ALTER TABLE users ADD INDEX idx_city_email_username (city, email, username) - 这个索引能让 WHERE + GROUP BY 一气呵成，不回表、不排序、不临时表——所有数据直接从索引叶子节点读出
- 注意：如果
city基数太低（比如只有 3 个值），该索引区分度差，要考虑是否加user_id等高区分列补强
JOIN 后聚合时，务必控制右表数据量
LEFT JOIN 的右表一旦没被有效过滤，中间结果集会指数级膨胀，临时表大小直接由 LEFT × RIGHT 决定，跟最终 SELECT 的字段数无关。
- 危险写法：
SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' GROUP BY u.id—— 若某用户有 10 万订单，这一行就撑爆内存临时表 - 安全写法：把右表约束提前到 JOIN 条件或子查询里：
SELECT u.name, cnt FROM users u LEFT JOIN (SELECT user_id, COUNT(*) AS cnt FROM orders WHERE created_at >= '2025-01-01' GROUP BY user_id) o ON u.id = o.user_id WHERE u.status = 'active' - 关键点：子查询先分组、再 JOIN，避免笛卡尔积；同时
orders上要有(created_at, user_id)索引支撑子查询的 GROUP BY - 极端场景可加
STRAIGHT_JOIN强制驱动顺序，但前提是 EXPLAIN 确认优化器真选错了表做驱动
真正难的不是建索引，而是识别哪些字段在 WHERE、GROUP BY、ORDER BY、SELECT 中是“同一批”——它们必须能被同一个联合索引覆盖，且顺序不能错。一旦漏掉一个环节（比如忘了把过滤条件列前置），前面所有优化都白搭。
