执行计划中最拖后腿的步骤通常是GroupAggregate、HashAggregate或Sort节点，因其常占总耗时70%以上；若其Actual Total Time高且Batches>1或Sort Method为external merge，则表明内存不足导致磁盘溢出。
怎么看执行计划里哪个步骤最拖后腿
直接看 EXPLAIN ANALYZE 输出中 Execution Time 和各节点的 Actual Total Time，重点盯住 GroupAggregate、HashAggregate 或 Sort 这几行——它们往往占总耗时 70% 以上。如果 Plans 下挂了子节点且子节点本身就很慢，说明分组前的数据源就已成瓶颈。
常见错误现象：HashAggregate 节点显示 Buckets: 131072 Batches: 4 Memory Usage: 128MB，意味着内存不够、被迫写磁盘（Batches > 1 就是危险信号）；Sort 节点出现 Sort Method: external merge Disk: 2456kB，说明排序溢出到磁盘，性能断崖下跌。
- PostgreSQL 中临时增大
work_mem（如SET work_mem = '64MB'）能快速验证是否内存不足导致的慢，但别在全局设太高，避免并发多时 OOM - MySQL 用户注意：
EXPLAIN FORMAT=JSON比传统格式更能看清grouping_operation的代价估算，尤其关注estimated_cost和sort_key字段 - 不要只信
Rows Removed by Filter数值大就去优化 WHERE——有时分组字段本身没索引，WHERE 再快也得把百万行全扫进来再分组
GROUP BY 字段没索引一定慢吗
不一定，但大概率会。关键看数据分布和分组粒度：如果 GROUP BY user_id 且 user_id 是主键或唯一索引，优化器常能走索引扫描+流式聚合（GroupAggregate 配合 Index Scan），避免建哈希表；但如果 GROUP BY substring(email, 1, 3) 这种表达式，索引基本失效。
使用场景差异明显：OLAP 类查询（如按日期+地区汇总订单）适合给 (date, region) 建联合索引；而 GROUP BY EXTRACT(YEAR FROM created_at) 这种函数操作，必须用函数索引（PostgreSQL）或生成列（MySQL 5.7+）才能生效。
- PostgreSQL 函数索引示例：
CREATE INDEX idx_orders_year ON orders ((EXTRACT(YEAR FROM created_at))) - MySQL 生成列+索引示例：
ALTER TABLE orders ADD COLUMN year_created INT AS (YEAR(created_at)) STORED; CREATE INDEX idx_year ON orders(year_created) - 联合索引顺序很重要：
GROUP BY a, b用(a, b)索引有效，反过来用(b, a)通常无效（除非 a 是常量条件）
用 DISTINCT 替代 GROUP BY 能提速吗
不能，而且往往更慢。因为 DISTINCT 在语义上等价于 GROUP BY 所有 SELECT 列，但优化器未必能做相同优化——尤其当 SELECT 中有聚合函数时，DISTINCT 会强制先去重再算聚合，顺序错乱可能引发额外排序或哈希。
典型错误现象：SELECT DISTINCT user_id, COUNT(*) FROM orders GROUP BY user_id 是语法错误（MySQL 会报错，PostgreSQL 允许但逻辑混乱）；正确写法只能是 SELECT user_id, COUNT(*) FROM orders GROUP BY user_id。
- 想“去重后统计”？确认需求本质：
COUNT(DISTINCT user_id)是单个聚合值，不是分组；GROUP BY order_date HAVING COUNT(DISTINCT user_id) > 100才是合理组合 -
DISTINCT ON（PostgreSQL 特有）可用于取每组最新一条，但它不等价于GROUP BY，也不解决分组性能问题，只是不同语义的工具 - 避免
SELECT DISTINCT *配合大表分组——它会让优化器放弃所有索引利用，退化为全表扫描+内存去重
聚合函数里嵌套子查询为什么让分组雪崩
因为子查询会在每一组内重复执行。比如 SELECT user_id, COUNT(*), (SELECT SUM(amount) FROM payments p WHERE p.user_id = o.user_id) FROM orders o GROUP BY user_id，子查询会为每个 user_id 单独跑一次，O(n²) 复杂度直接压垮数据库。
性能影响极显著：1000 个用户，子查询若平均耗时 5ms，光这部分就增加 5 秒；而改用 JOIN + 窗口函数或预聚合，通常能压到 200ms 内。
- 优先用 JOIN：
SELECT o.user_id, COUNT(*), COALESCE(p.total, 0) FROM orders o LEFT JOIN (SELECT user_id, SUM(amount) total FROM payments GROUP BY user_id) p ON o.user_id = p.user_id GROUP BY o.user_id - MySQL 8.0+/PostgreSQL 支持窗口函数替代部分场景：
SUM(amount) OVER (PARTITION BY user_id)可避免分组前的嵌套计算 - 警惕隐式子查询：视图、CTE 如果定义里含聚合，又被外层 GROUP BY 引用，同样触发重复执行——先展开 CTE 看执行计划，别信“CTE 是物化”的直觉
最容易被忽略的是分组字段的 NULL 处理：如果 GROUP BY category 中 category 有大量 NULL，PostgreSQL 会把所有 NULL 归为同一组，但索引通常跳过 NULL，导致这部分数据只能走顺序扫描——加个 WHERE category IS NOT NULL 或单独建 INDEX ON t (category) WHERE category IS NOT NULL 常有奇效。
