MySQL的GROUP BY+ORDER BY查询不走索引，是因为索引字段顺序必须严格匹配WHERE等值条件、GROUP BY列序和ORDER BY列序的最左前缀；复合索引不能包含聚合函数结果，但可将参与过滤或排序的原始列按需置于末尾以避免filesort；时间字段单独建索引效果差，应作为复合索引后缀；分区表不能替代索引，需与复合索引协同使用。
MySQL 的 GROUP BY + ORDER BY 查询为什么总不走索引？
因为 MySQL 对多维分析类查询（比如按 region、product_type、year_month 分组聚合再排序）默认很难利用单一 B+ 树索引覆盖全部操作。它常被迫先用索引找数据，再回表排序或临时文件排序，甚至放弃索引直接全表扫描。
关键不是“有没有索引”，而是索引字段顺序是否匹配查询的 GROUP BY 列序 + ORDER BY 列序 + WHERE 过滤条件的最左前缀。
-
WHERE region = 'CN' AND product_type = 'mobile'→ 索引应以(region, product_type)开头 - 接着要
GROUP BY year_month, category→ 后续列必须严格按此顺序追加，如(region, product_type, year_month, category) - 若还
ORDER BY sales_amount DESC，且需避免 filesort，则sales_amount必须是索引最后一列（但注意：含范围条件时，其后的列无法用于索引查找）
复合索引中该不该包含聚合字段（如 SUM(sales)）？
不能。MySQL 索引只存储原始列值，不存储计算结果。你无法为 SUM(sales) 建索引，但可以为参与聚合的维度列（region, year_month 等）建索引，让 MySQL 快速定位、分组、跳过无关数据块。
真正提升 OLAP 查询效率的是「减少扫描行数」和「避免临时表/排序」，不是加速求和本身。
- 聚合字段（
sales,quantity）适合放在索引末尾，仅当它们用于WHERE（如sales > 100）或需要ORDER BY且前面全是等值条件时才有效 - 如果查询只
SELECT region, year_month, COUNT(*), SUM(sales)，且有索引(region, year_month)，MySQL 可能用“索引覆盖”（Using index），完全不查数据页 - 加冗余列如
(region, year_month, sales)不会加速SUM(sales)，但能让WHERE sales > 50走索引下推（ICP）
为什么给时间字段建单独索引对 OLAP 查询基本没用？
因为 OLAP 查询极少只按时间单维度过滤；更常见的是 WHERE region = ? AND year_month BETWEEN ? AND ?。此时单独的 year_month 索引因选择性低（时间范围大）、无法配合其他维度，优化器大概率弃用。
正确做法是把高频过滤的时间字段作为复合索引的后缀，而非前缀——除非它是唯一过滤条件。
- 错误示例：
INDEX(year_month, region)→WHERE region = 'US'无法使用该索引（不满足最左前缀） - 合理示例：
INDEX(region, year_month)→ 支持WHERE region = 'US'或WHERE region = 'US' AND year_month >= '2024-01' - 对按月滚动分析，考虑用
DATE字段替代字符串year_month，便于范围查询和分区裁剪
分区表（PARTITION BY RANGE）能替代索引吗？
不能替代，但可协同。分区是“粗筛”，索引是“细筛”。没有合适索引，即使落在单个分区里，仍可能全分区扫描。
典型陷阱：按 year_month 分区，却在查询中只用 region 过滤 → 所有分区都要打开检查。
- 分区键最好与高频查询的最左过滤字段一致，例如按
regionLIST 分区 + 每个分区内建(year_month, category)索引 -
EXPLAIN PARTITIONS必须看到partitions列只显示少数几个分区名，否则分区未生效 - MySQL 8.0+ 支持二级分区，但维护成本高；多数场景下，一个合理设计的复合索引比过度依赖分区更稳定可靠
多维分析索引的本质是预测查询模式：哪些列总是一起出现？哪个是强过滤？哪个是分组主键？哪个决定排序稳定性？把这些写进索引定义里，而不是堆砌字段或迷信“全字段索引”。
