GROUP BY 字段不必有索引，但无索引时易触发全表扫描和文件排序；索引需按GROUP BY列顺序创建且不被WHERE打断才能优化分组；count(*)/COUNT(1)可走最小索引，COUNT(col)需考虑NULL；MAX/MIN可O(1)取索引端点，SUM/AVG需索引覆盖；EXPLaiN显示type=ALL常因函数、类型转换或统计信息过期导致。
GROUP BY 字段必须有索引才有效吗？
不是必须，但没索引时 GROUP BY 往往触发全表扫描 + 内存排序（using filesort），性能急剧下降。mysql 8.0+ 和 postgresql 会尝试用索引跳扫（loose index scan）或紧凑索引扫描（tight index scan），前提是索引顺序匹配 GROUP BY 列顺序，且没有被 WHERE 条件“打断”。
实操建议：
- 复合索引要按
GROUP BY列的顺序前置，例如GROUP BY user_id, status→ 建索引(user_id, status)，而非(status, user_id) - 如果
WHERE条件用了非前导列（如WHERE status = 'active'+GROUP BY user_id），即使有(status, user_id)索引，也可能无法跳过排序 - PostgreSQL 中
GROUP BY可利用索引仅当查询不包含非分组列的聚合外字段（即不能select *或混用未聚合的列）
COUNT(*)、COUNT(1)、COUNT(col) 走不走索引？
COUNT(*) 和 COUNT(1) 在 InnoDB 中基本等价，优化器通常选择最小的可用二级索引（甚至主键聚簇索引）来遍历行数，不一定要全表扫；但 COUNT(col) 必须检查 col 是否为 NOT NULL：若该列允许 NULL，就必须访问数据行或至少该列的索引（如果有单列索引且覆盖非空判断）。
实操建议：
- 想加速
COUNT(*)，确保表有主键（InnoDB 强制要求），避免无主键表——它会退化为逐行计数 - 对可空列
col做COUNT(col)，建INDEX (col)有助于跳过 NULL 行（前提是引擎支持索引 NULL 值过滤，如 InnoDB 支持） - 不要用
COUNT(*)在大表上做实时总数统计，考虑缓存或近似值（如SHOW table STATUS的Rows字段，仅作参考）
SUM() / AVG() / MAX() / MIN() 能否用索引下推？
可以，但依赖索引结构和查询写法。最典型的是 MAX(col) 和 MIN(col)：如果 col 有 B-Tree 索引，优化器常直接取索引最左/最右叶节点值，O(1) 完成；SUM() 和 AVG() 则需遍历索引范围，但仍比回表快得多——前提是索引覆盖所有参与计算的列（即不需要回表取其他字段）。
实操建议：
-
SELECT MAX(created_at) FROM orders WHERE status = 'shipped'→ 索引(status, created_at)可让 MySQL 直接在索引中定位到第一个匹配status的最大created_at - 若写成
SELECT SUM(amount) FROM sales WHERE region = 'CN' GROUP BY product_id，索引(region, product_id, amount)是覆盖索引，全程走索引，不回表 - 注意
AVG(col)等价于SUM(col)/COUNT(col)，所以同样受col是否可空影响执行计划
为什么加了索引，EXPLAIN 还显示 type=ALL？
常见原因不是索引没建，而是查询结构破坏了索引使用条件。比如 GROUP BY UPPER(name) 无法用 name 索引；WHERE col != 'x' GROUP BY col 在多数版本中无法用索引做分组扫描；或者统计信息过期导致优化器误判成本。
排查步骤：
- 运行
ANALYZE TABLE tbl_name更新统计信息（MySQL）或VACUUM ANALYZE tbl_name（PostgreSQL） - 检查
WHERE中是否对索引列用了函数、表达式、隐式类型转换（如WHERE id = '123'对 int 列） - 用
EXPLAIN format=jsON查看used_key_parts和group_key_subpart字段，确认哪些索引部分实际被用于分组
索引对聚合的影响高度依赖具体 SQL 结构和优化器版本，同一句查询在 MySQL 5.7 和 8.0 中执行路径可能完全不同；别只看有没有索引，重点看执行计划里是否真正“用上”了。