PostgreSQL中GROUP BY+MAX()查询未用索引且强制索引更慢问题

安全阿岳

2026-5-9

问题分析与解决思路

这问题我在PostgreSQL运维中碰到过好几次，咱们一步步拆解为什么会出现这种反直觉的情况，以及怎么解决：

一、为什么索引没被自动选用？

PostgreSQL的查询优化器（Planner）会根据统计信息估算不同执行计划的成本，它不选你的索引，大概率是这些原因：

统计信息过时：如果表最近有大量数据插入/更新，却没跑ANALYZE，Planner会误判数据分布（比如觉得id的基数很低、或者表行数很少），认为顺序扫描的成本更低。
索引成本估算偏差：默认的random_page_cost（随机IO成本）是4，如果你用的是SSD，这个值偏高，Planner会觉得索引的随机IO开销太大，不如顺序扫描的连续IO划算。
索引没被当成覆盖索引：你的索引包含id和time，理论上可以做仅索引扫描（Index Only Scan），但如果表的可见性映射（VM）没更新（比如很久没做VACUUM），Planner会认为需要回表验证行的可见性，直接放弃用索引。

当你关闭enable_seqscan后，Planner只能硬着头皮用索引，但这时候可能触发了更差的执行路径：

被迫做全索引扫描+回表：如果没法用仅索引扫描，每一条索引记录都要回表对应的数据块，随机IO的开销直接爆炸——顺序扫描是连续读整块数据，而索引扫描是跳着读，IO效率差很多。
索引遍历的额外开销：如果你的id基数极高（比如每个id只有1-2行），遍历整个索引的开销其实比顺序扫描全表还大——顺序扫描可以在扫表过程中直接计算每个id的最大值，而索引扫描需要先按id排序遍历，再聚合计算，多了一层处理。

按优先级试这些方案：

这是最基础也最有效的第一步：

-- 同时更新统计信息和可见性映射
VACUUM ANALYZE table;

跑完之后再跑EXPLAIN ANALYZE看看，Planner大概率会自动选择更优的计划——如果能触发仅索引扫描，速度会有明显提升。

你的分组取最大值查询，可以换成DISTINCT ON的写法，PostgreSQL对这种写法的索引支持更友好：

SELECT DISTINCT ON (id) 
       id, time AS max_time
FROM table
ORDER BY id, time DESC NULLS LAST;

这个写法会直接利用你建的(id, time DESC NULLS LAST)索引，按顺序遍历索引就能拿到每个id的最大time，不需要额外聚合。

如果索引有碎片（比如表频繁更新），重建索引能提升扫描效率：
```
REINDEX INDEX table_time_and_id;
```
确认索引的排序方向和查询完全匹配：你的索引是time DESC NULLS LAST，查询里的MAX(time)也对应这个排序，这点没问题，但如果查询里没指定NULLS LAST，可能会导致Planner不匹配索引（因为PostgreSQL默认NULL排序在最后，但显式指定更保险）。

如果你用的是SSD存储，可以降低random_page_cost，让Planner更倾向于索引扫描：

-- 会话级临时调整，测试效果
SET LOCAL random_page_cost = 1.1;
-- 如果有效，可以在postgresql.conf里全局设置

注意：这个参数会影响所有查询的计划选择，一定要先测试再全局生效。

内容的提问来源于stack exchange，提问作者Lesto