在MySQL中，当一条SQL同时按多个字段进行GROUP BY时，例如按用户、状态、日期三个维度统计订单量，执行计划常常会出现Using temporary和Using filesort。这意味着MySQL需要先读取数据，然后建立临时表来存放分组结果，如果内存临时表放不下还会落盘，查询延迟明显上升。很多优化尝试单纯在某个分组字段上建立单列索引，但效果有限。问题不在单列索引，而在于分组字段的读取顺序无法与索引的物理顺序匹配。复合索引可以同时覆盖多个分组列，让优化器按索引顺序扫描就能完成分组，省去临时表和排序。
多维度分组查询的执行特征与临时表代价
MySQL处理GROUP BY通常有两种路径：一种是通过索引顺序扫描，直接利用索引的有序性完成分组；另一种是扫描数据后写入临时表，再对临时表进行排序或分组。对于多维度分组，如果查询涉及的字段分散在多个单列索引上，或者根本没有合适的索引，优化器只能选择第二种路径。此时执行计划中的Extra列会显示Using temporary; Using filesort，这表明查询正在创建临时表，并且可能需要在磁盘上完成排序操作。
临时表分为内存临时表和磁盘临时表。内存临时表默认使用MEMORY引擎，当数据量超过tmp_table_size或max_heap_table_size的限制时，MySQL会将其转换为磁盘临时表。磁盘临时表可能使用MyISAM或InnoDB引擎，写入和读取都会产生额外的I/O开销。对于大表来说，这个过程可能让原本几百毫秒的查询变成几秒甚至更久。下面是一个典型的多维度分组查询示例：
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
user_id BIGINT NOT NULL,
status TINYINT NOT NULL,
created_at DATETIME NOT NULL,
amount DECIMAL(10,2) NOT NULL,
INDEX idx_user (user_id),
INDEX idx_status (status),
INDEX idx_created (created_at)
) ENGINE=InnoDB;
SELECT user_id, status, DATE(created_at) AS stat_date, COUNT(*)
FROM orders
WHERE created_at >= '2024-01-01'
GROUP BY user_id, status, stat_date;
这条SQL按用户、状态、日期三个维度分组，虽然相关字段各自都有单列索引，但优化器无法同时利用三个独立的索引来满足分组顺序，最终只能扫描满足条件的全部行，然后建立临时表按分组列排序。即使只给其中一个字段建立索引，也不能解决另外两个字段带来的排序问题。这就是为什么多维度分组场景下，单列索引往往收效甚微。
复合索引的最左前缀原则与字段顺序
复合索引的底层是B+树，索引中的记录会按照定义索引时指定的列顺序依次排序。例如创建INDEX idx_user_status_date(user_id, status, created_date)，B+树会先按user_id排序，user_id相同的记录再按status排序，status相同的记录再按created_date排序。这种结构天然适合GROUP BY user_id, status, created_date这样的分组需求，因为相同user_id、status、created_date的行在索引中连续存放，优化器可以顺序扫描索引，一旦发现分组键发生变化，就直接输出上一组的结果，不需要额外排序。
最左前缀原则要求查询中的分组字段必须从复合索引的最左列开始，并且保持连续。如果索引是(user_id, status, created_date)，那么GROUP BY user_id, status可以使用该索引，GROUP BY user_id, created_date则只能使用user_id这一列，因为中间跳过了status，索引的有序性在created_date上被破坏。同样，GROUP BY status, created_date完全不能使用该索引，因为缺少最左的user_id。因此，在设计复合索引时，需要把最常作为分组条件且区分度较高的字段放在前面。
字段顺序还应该考虑查询的WHERE条件。如果WHERE中经常出现status = 1这样的等值过滤，并且GROUP BY中也包含status，那么把status放在索引中靠前的位置可以减少扫描范围。但也要注意，如果等值过滤后的status取值固定，实际上分组时status值已经确定，索引顺序中status列对分组的意义会减弱。此时可能需要根据实际统计信息调整顺序，让真正区分分组的列位于索引中更关键的位置。
覆盖索引与松散索引扫描
覆盖索引指的是查询需要的所有列都包含在索引中，MySQL不必回表读取完整行数据。对于COUNT(*)分组统计，如果复合索引包含了所有分组字段，优化器可以只遍历索引的叶子节点就能得到每个分组的行数，完全避免访问主键索引。这种扫描方式配合分组优化，能够大幅减少I/O。执行计划中Extra列会显示Using index，代表覆盖索引生效。
松散索引扫描是MySQL针对GROUP BY的一种更高效的优化。当分组字段是索引的最左前缀时，优化器可以跳过索引中重复的分组键值，只读取每个分组的第一个条目，然后通过索引统计信息获取该分组的行数。这种方式的时间复杂度与分组数量成正比，而无需扫描所有行。例如对于复合索引(user_id, status, created_date)，执行GROUP BY user_id, status时，MySQL可以快速定位每个(user_id, status)组合的起始位置，然后跳到下一个组合。执行计划中会显示Using index for group-by。
松散索引扫描需要满足一些条件：查询必须是单表，GROUP BY的列必须全部来自同一索引且按顺序从最左开始，SELECT列表中只能包含分组列和聚合函数，不能包含其他非索引列。如果条件不满足，优化器可能退化为紧凑索引扫描，虽然仍然使用索引，但需要扫描所有索引条目才能完成分组。紧凑索引扫描比临时表方案好，但不如松散索引扫描高效。因此，在设计复合索引时，尽量让分组查询满足松散索引扫描的条件，可以进一步提升性能。
实战：优化订单统计查询的完整过程
假设有一张订单表orders，业务上需要按用户、状态和下单日期统计订单数量。最初的查询写法如下：
SELECT user_id, status, DATE(created_at) AS stat_date, COUNT(*) FROM orders GROUP BY user_id, status, stat_date;
执行计划的Extra列显示Using temporary; Using filesort，查询耗时随着订单量增长持续上升。第一个需要解决的问题是对created_at使用DATE()函数，这个操作会阻止优化器直接使用created_at上的索引，因为索引存储的是原始DATETIME值，而不是函数计算后的结果。如果业务统计只关心日期粒度，可以在表结构中增加一个生成列created_date，并为其建立索引。
ALTER TABLE orders ADD COLUMN created_date DATE AS (DATE(created_at)) STORED; CREATE INDEX idx_user_status_date ON orders(user_id, status, created_date);
然后调整查询语句，直接按生成列进行分组：
SELECT user_id, status, created_date, COUNT(*) FROM orders GROUP BY user_id, status, created_date;
再次查看执行计划，Extra列中的Using temporary; Using filesort消失，取而代之的是Using index for group-by。这说明查询已经通过复合索引完成分组，不再建立临时表。如果表结构无法修改，也可以利用MySQL 8.0的函数索引来完成类似效果：
CREATE INDEX idx_user_status_func ON orders(user_id, status, (DATE(created_at))); SELECT user_id, status, DATE(created_at), COUNT(*) FROM orders GROUP BY user_id, status, DATE(created_at);
函数索引会存储表达式计算后的结果，这样优化器在分组时可以直接利用索引。不过函数索引会增加写入时的计算成本，需要根据业务场景权衡。在实际优化中，生成列配合普通复合索引通常是更稳妥的方案，因为生成列的值在插入时已经计算好，不增加查询时的函数开销。
其他辅助优化手段与注意事项
除了建立复合索引，还可以通过调整MySQL的临时表参数来缓解磁盘临时表带来的性能问题。tmp_table_size和max_heap_table_size决定了内存临时表的最大容量，适当增大这两个参数可以让更多分组操作在内存中完成。但这只是治标不治本，如果分组本身需要处理大量数据，内存临时表再大也会触顶，最终仍会落盘。根本方案仍然是让优化器通过索引避免临时表。
另一个容易忽视的细节是分组字段上的表达式或函数。例如在GROUP BY中使用LOWER(region)或SUBSTRING(order_no, 1, 6)，即使region或order_no本身有索引，表达式也会破坏索引的可用性。如果确实需要按函数结果分组，应该优先考虑生成列或函数索引，把计算提前到写入阶段。
当SQL同时包含WHERE、GROUP BY和ORDER BY时，索引的利用会更加复杂。理想情况下，一个复合索引能够同时满足过滤、分组和排序的需求。例如WHERE user_id = 1001 AND status = 1 GROUP BY user_id, status, created_date ORDER BY created_date LIMIT 10，如果索引是(user_id, status, created_date)，过滤和分组都能利用索引顺序，ORDER BY也不需要在临时表基础上再排序。因此，在设计索引时建议先梳理出高频的查询组合，再确定索引列的顺序，优先满足分组和排序的连续性。
还有一种情况需要警惕：当分组字段的基数非常大时，松散索引扫描可能需要频繁跳转，此时索引扫描的随机I/O成本可能超过建立临时表并排序的成本。优化器会根据统计信息自动选择路径，但有时统计信息不准确会导致错误判断。可以通过ANALYZE TABLE更新统计信息，或者使用FORCE INDEX强制指定索引，但强制索引需要经过充分测试，避免引发其他查询的性能回退。
多维度分组查询的优化核心在于让分组字段的顺序与复合索引的物理顺序对齐，并尽可能利用覆盖索引和松散索引扫描来省去临时表。通过生成列或函数索引解决表达式分组问题，再结合合理的临时表参数调整，可以让这类查询在大数据量下保持较低的响应时间。