在MySQL中，合理使用索引可以显著提升聚合查询（如COUNT、SUM、AVG、MAX、MIN等）的执行效率。聚合操作通常涉及大量数据扫描，若没有合适的索引支持，会导致全表扫描，严重影响性能。通过为参与聚合或过滤的列建立索引，可大幅减少需要读取的数据量。
选择合适的列创建索引
聚合查询中最常用于提升性能的是对GROUP BY、WHERE 和 ORDER BY 子句中的列建立索引。
如果查询中有 GROUP BY user_id，则应在 user_id 上创建索引。 若同时有 WHERE status = 1 和 GROUP BY user_id，考虑建立复合索引 (status, user_id)。 对于 MAX(id) 或 MIN(id) 这类查询，主键或唯一索引本身就足够高效，因为B+树结构允许快速定位最左或最右叶子节点。利用覆盖索引避免回表
覆盖索引是指索引包含查询所需的所有字段，这样MySQL无需访问数据行即可完成查询，极大提升性能。
例如：SELECT user_id, COUNT(*) FROM orders WHERE status = 1 GROUP BY user_id；若存在复合索引 (status, user_id)，该索引可能直接满足查询需求。 使用 EXPLAIN 分析执行计划，查看是否出现 "Using index"，表示使用了覆盖索引。优化聚合函数的索引策略
不同聚合函数对索引的依赖方式不同，应针对性优化。
COUNT(*) 在无 WHERE 条件时，InnoDB 需要扫描聚簇索引；但如果有 WHERE 条件，对应列的索引能加快过滤。 COUNT(column) 会忽略 NULL 值，若该列有非空索引，可加速统计。 MAX/MIN 在有索引的列上非常快，尤其是主键或唯一索引，几乎常数时间完成。 SUM/AVG 无法直接从索引获取结果，除非配合覆盖索引减少I/O开销。注意索引维护成本与选择性
虽然索引能提升查询速度，但也会增加写操作的开销，并占用存储空间。
避免在低选择性的列（如性别、状态码）单独建索引，除非与其他高选择性列组合成复合索引。 定期分析表结构和查询模式，删除冗余或未使用的索引。 使用 SHOW INDEX FROM table_name 查看现有索引，结合慢查询日志识别瓶颈。基本上就这些。关键是在理解查询逻辑的基础上，设计出既能支撑聚合操作又能最小化额外开销的索引结构。不复杂但容易忽略细节。
