SQL聚合性能取决于索引是否能缩小扫描范围，而非函数本身；WHERE过滤、GROUP BY分组、COUNT类型及索引设计匹配度共同决定索引能否加速聚合。
SQL 聚合函数本身不直接“使用”索引，但查询执行计划中，底层扫描的数据范围是否能借助索引快速定位，会极大影响聚合性能。关键不在函数本身，而在它作用的列、WHERE 条件、GROUP BY 字段以及索引的设计是否匹配。
WHERE 条件 + 聚合：索引最常生效的场景
当你对带过滤条件的聚合（如 COUNT(*) WHERE status = 'active'）进行查询时，数据库会优先用索引快速定位满足条件的行，再对这些行做聚合。只要 status 列上有索引（单列或复合索引的前导列），就能跳过大量无关数据。
- ✅ 推荐：为高频过滤字段建索引，例如
CREATE INDEX idx_orders_status ON orders(status); - ⚠️ 注意：如果
WHERE status IN ('a','b','c')返回数据量过大（比如占全表 30% 以上），优化器可能放弃索引走全表扫描——此时索引对聚合的帮助就减弱了。
GROUP BY + 聚合：索引可避免排序和临时表
当查询含 GROUP BY column 和聚合（如 SUM(amount)），若 column 有索引，数据库可能直接按索引顺序读取数据，天然有序，省去额外排序；某些引擎（如 MySQL 的 Index Merge 或 PostgreSQL 的 Index-Only Scan）还能仅靠索引完成聚合，完全不回表。
- ✅ 推荐：对常用分组字段建索引，尤其是组合分组（如
GROUP BY dept_id, year）时，建立联合索引(dept_id, year)效果更佳。 - ⚠️ 注意：如果 SELECT 中包含非 GROUP BY 非聚合的列（如
SELECT dept_id, name, SUM(salary)），通常无法只靠索引完成，仍需回表——这时索引对聚合的加速有限。
COUNT(*) 与 COUNT(列)：索引覆盖决定是否免扫描
COUNT(*) 统计行数，若使用聚簇索引（如 InnoDB 的主键），优化器有时能直接查索引元数据（尤其无 WHERE 时），速度极快；COUNT(非空列) 在该列有非空约束且有索引时，也可能走索引扫描（比全表轻）；但 COUNT(可空列) 必须检查每行值是否为 NULL，一般无法跳过数据页。
- ✅ 小技巧：想快速估算大表总行数？可用
EXPLAIN SELECT COUNT(*) FROM t;查看是否显示 “Using index”；或依赖统计信息（如SHOW TABLE STATUS中的Rows字段，但它是估算值）。 - ⚠️ 提醒：没有 WHERE 的
COUNT(*)在大表上仍可能慢——索引再快，也得遍历所有索引节点；真正高效的方式是业务层维护计数器或用近似统计函数（如 HyperLogLog）。
索引失效的常见坑
即使建了索引，以下写法会让优化器放弃使用它来加速聚合：
- 在聚合字段或 WHERE 字段上用了函数或表达式：如
WHERE YEAR(created_at) = 2023（应改用created_at >= '2023-01-01' AND created_at ） - 对字符串字段用
LIKE '%abc'—— 前导通配符导致无法利用 B+ 树索引的有序性 - 隐式类型转换：如
WHERE user_id = '123'（user_id 是 INT），可能触发全表扫描
