GROUP BY必须用复合索引，单列索引基本无效；因MySQL和PostgreSQL仅支持最左前缀匹配，要求索引列顺序与GROUP BY字段顺序完全一致，否则触发Using temporary和filesort。

GROUP BY 必须用复合索引，单列索引基本无效

MySQL 和 PostgreSQL 对 GROUP BY 的优化只认最左前缀匹配，且要求索引列顺序与 GROUP BY 字段顺序完全一致。比如 GROUP BY region, city, category，只有 (region, city, category) 或 (region, city, category, amount) 这类索引能跳过排序和临时表；而 (city, region)、(region, category)，甚至三个单列索引，都会触发 Using temporary 和 Using filesort。

常见错误是给每个分组字段单独建索引——这不仅不加速分组，还增加写入延迟和磁盘占用。

• 单列索引无法满足多字段分组的有序归并需求
• 数据库必须先将数据读出、排序、再分桶聚合，I/O 和 CPU 开销陡增
• EXPLAIN 中一旦出现 Using temporary，说明当前索引没生效，不是警告，是已失败

复合索引字段顺序必须严格匹配 GROUP BY 顺序

索引列的顺序，绝不是“把字段都放进去能覆盖就行”这么简单，关键在于它必须和 GROUP BY 子句里字段的出现顺序完全一致。哪怕只是前后颠倒了一个位置，结果都可能完全不同。比如查询写的是 GROUP BY user_id, status，可索引却建成了 (status, user_id)，那数据库依然没法借助这个索引完成有序分组，最终还是会退回到临时表。

WHERE 条件字段要前置：如 WHERE active = 1 GROUP BY dept_id，索引应为 (active, dept_id)，让过滤和分组在一次索引扫描中完成。

• 高选择性字段（如 active、status）放左边，低选择性字段（如 gender）放右边，避免前缀区分度低导致整条索引失效
• 如果还要支持 A VG(salary)，把 salary 加在最后： (active, dept_id, salary) —— 这样才能形成覆盖索引，避免回表
• 别在末尾硬加无关字段，比如只查 dept_id 和 COUNT(*)，却建 (active, dept_id, name, email)，徒增索引体积

隐式类型转换会让复合索引彻底失效

就算索引顺序一点没错，只要 WHERE 或 JOIN 条件里混进了隐式类型转换，索引往往也会被直接绕开。最常见的情况就是：user_id 明明是 BIGINT，查询却写成了 WHERE user_id = '123'（字符串），这时候 MySQL 通常就不会再使用 (user_id)，以及任何以 user_id 开头的复合索引。

中间表 JOIN 也常踩这个坑：比如 orders.id 是 BIGINT，而 order_product.order_id 是 INT，JOIN 时隐式转换会让两边索引都失效。

• 用 SHOW CREATE TABLE 对比两端字段定义，确保类型、符号性（SIGNED/UNSIGNED）、长度（如 VARCHAR(32) vs VARCHAR(64)）完全一致
• 字符串字段还要检查字符集和排序规则：utf8mb4_general_ci 和 utf8mb4_unicode_ci 不兼容，也会让索引失效
• EXPLAIN 输出中若 type 是 ALL 或 index，且 key 列为空，大概率就是类型不一致或隐式转换

覆盖索引不是“把 SELECT 所有字段塞进索引”

覆盖索引的核心目标是让数据库不用回表就能拿到全部所需数据。关键看 EXPLAIN 输出：key 显示用了哪个索引，且 Extra 里不能有 Using temporary 或 Using filesort，同时 SELECT 和 GROUP BY 字段全在索引定义中。

例如：SELECT dept_id, COUNT(*), A VG(salary) FROM emp WHERE active = 1 GROUP BY dept_id，理想索引是 (active, dept_id, salary) —— active 过滤，dept_id 分组，salary 支持 A VG() 聚合，三者都在索引里。

• 函数索引可用但有限制：MySQL 8.0+ 支持 INDEX idx_date ON orders((DATE(create_time)))，老版本只能靠生成计算列 + 索引
• 对高基数字段（如 UUID、手机号）分组，极易触发磁盘临时表；优先考虑降维（如 IP → 地区）、预聚合或 OLAP 引擎替代
• 别忽略 tmp_table_size 和 max_heap_table_size 的实际限制——它们只是兜底，不能替代索引设计

真正卡住性能的，往往不是没建索引，而是索引建了但顺序错、类型错、字段冗余，或者根本没意识到 Using temporary 是已经失败的信号。