SQL聚合函数本身不直接使用索引，但优化器可借助匹配的索引避免全表扫描：覆盖索引加速COUNT/SUM、B+树有序性支撑MIN/MAX高效定位、GROUP BY前缀匹配索引可免排序，而函数、类型转换等会破坏索引有效性。
SQL聚合函数（如 COUNT()、SUM()、AVG()、MIN()、MAX()）本身不直接“使用索引”执行计算，但数据库优化器可借助索引加速聚合过程——前提是索引结构与查询模式匹配。关键不在于函数是否“调用索引”，而在于能否避免全表扫描，转而利用索引的有序性、覆盖性或最值定位能力。
覆盖索引让 COUNT() 和 SUM() 飞起来
当聚合操作仅涉及索引列时，数据库可直接遍历索引页完成计算，无需回表读取数据行。这大幅减少 I/O 开销。
- COUNT(*)：若存在任意非空索引（如主键），优化器常选择最小索引树（如 InnoDB 的聚簇索引）快速统计叶子节点数量；显式建一个紧凑的二级索引（如 INDEX idx_status (status)）也能加速 COUNT(status)（忽略 NULL）
- SUM(amount) 或 AVG(amount)：建覆盖索引 INDEX idx_user_amount (user_id, amount)，配合 WHERE user_id = ?，就能在索引中完成过滤 + 聚合，不触达聚簇索引
索引有序性直接支撑 MIN()/MAX()
B+ 树索引天然有序，首尾叶子节点即对应最小/最大值。只要 WHERE 条件能将搜索范围收敛到索引的连续片段，MIN/MAX 就可能实现 O(1) 或 O(log n) 定位。
- 单列索引 INDEX idx_created (created_at)：查询 SELECT MIN(created_at) FROM orders 可直接取索引最左节点；SELECT MAX(created_at) WHERE status = 'paid' 则需该列也在索引中（如 INDEX idx_status_created (status, created_at)）
- 避免写成 SELECT MIN(col) FROM t ORDER BY col LIMIT 1 —— 语义等价但无法触发索引最值优化，易走全索引扫描
GROUP BY + 索引：排序免排序，分组更高效
当 GROUP BY 字段顺序与索引前缀一致，且无复杂表达式时，数据库可利用索引物理顺序流式分组，省去临时表和文件排序。
- 索引 INDEX idx_city_type (city, product_type) 可高效支持：SELECT city, product_type, COUNT(*) FROM sales GROUP BY city, product_type
- 若查询是 GROUP BY product_type, city（顺序颠倒），则索引失效；若含 HAVING COUNT(*) > 10，仍需聚合后过滤，但索引已帮它更快分好组
- 加 WHERE city IN ('Beijing', 'Shanghai') 会进一步缩小扫描范围，提升效率
注意陷阱：函数、类型转换和 NULL 让索引失效
看似用了索引，聚合却没受益，往往因隐式操作破坏了索引可用性。
- SELECT COUNT(*) FROM t WHERE YEAR(create_time) = 2024：对字段应用函数，无法走 INDEX(create_time)；应改写为 create_time >= '2024-01-01' AND create_time < '2025-01-01'
- SELECT AVG(price) FROM products WHERE category_id = '123'：若 category_id 是 INT 类型，但传入字符串 '123'，触发隐式类型转换，可能导致索引失效
- COUNT(column) 会跳过 NULL 值，若该列 NULL 比例高，实际扫描行数可能远少于 COUNT(*)，但索引选择逻辑仍取决于是否覆盖、是否有序
