聚合查询超时八成因全表扫描，需检查执行计划中type是否为all、key是否为空、rows_examined是否过大；确保group by字段在索引最左前缀，避免函数包裹聚合字段及过滤条件。
查执行计划里有没有全表扫描
聚合查询超时，八成是优化器没走索引，硬扫了大表。比如 COUNT(*) 或 SUM(amount) 对千万级表没加 WHERE，或者加了但字段没索引，type 就会是 ALL；key 列为空，rows_examined 动辄百万以上。
- 用
EXPLAIN（MySQL）、SET STATISTICS XML ON（SQL Server）或EXPLAIN ANALYZE（PostgreSQL）看真实执行路径 - 特别注意
GROUP BY字段是否在索引最左前缀上——INDEX(a, b)支持GROUP BY a，但不支持GROUP BY b - 如果聚合字段本身被函数包裹，比如
SUM(IF(status = 'paid', amount, 0))，即使有索引也大概率失效
确认聚合前是否做过有效过滤
很多人写 SELECT COUNT(*) FROM orders GROUP BY user_id，却不加 WHERE create_time >= '2026-07-01'，结果每次都在全量历史数据上分组——哪怕最终只返回几百行，中间也要处理几千万行。
- 先查调用方传入的过滤条件是否落在索引列上，而不是只看视图或存储过程里有没有
WHERE - 避免在过滤条件里用函数：
WHERE DATE(created_at) = '2026-08-01'→ 改成WHERE created_at >= '2026-08-01' AND created_at - 对高基数字段（如
user_id）做GROUP BY时，若没配合时间范围限制，极易触发大量临时表和磁盘排序
检查统计信息是否过期
聚合涉及大量行估算，一旦统计信息陈旧，优化器就会低估数据分布，选错执行计划。比如 COUNT(DISTINCT user_id) 在用户活跃度突增后仍按旧统计估算，可能放弃哈希聚合而选嵌套循环，耗时翻倍。
- SQL Server 执行
UPDATE STATISTICS 表名 WITH FULLSCAN；MySQL 运行ANALYZE TABLE 表名 - 重点关注
HISTOGRAM类型字段（如时间分区列、状态码），它们对聚合行数预测影响最大 - 专用 SQL 池等 MPP 架构下，必须手动
REBUILD聚集列存储索引，否则统计信息无法自动刷新
警惕隐式类型转换和 NULL 处理开销
COUNT(column) 看似轻量，但如果该列允许 NULL 且实际 NULL 值占比高，引擎就得逐行判断；更麻烦的是隐式转换——比如 WHERE order_no = 12345（order_no 是 VARCHAR），会导致整列 CAST，索引失效，聚合前扫描爆炸。
- 用
ISNULL()或COALESCE()包裹聚合字段时，务必确认底层列类型与表达式一致 -
GROUP BY中混用不同精度数值类型（如DECIMAL(10,2)和FLOAT）会触发隐式转换，拖慢分组哈希构建 - PostgreSQL 中
COUNT(*)比COUNT(id)快得多，因为前者跳过 NULL 检查；但 SQL Server 两者差异不大，重点还是看执行计划里的EstimatedRows是否严重偏离实际
rows_examined 和 tempdb_usage 这两个数字，比超时时间更能说明问题。
