PostgreSQL带ORDER BY与LIMIT的慢查询异常问题咨询

这事儿我太熟了，典型的PostgreSQL查询优化器估算偏差导致的问题，咱们一步步捋清楚：

核心原因：优化器的行数估算与实际不符 #

先看你的执行计划：优化器估算符合fk_id='73a711a5-cb31-545d-b8d6-75c2a0e3ba9d'的行数是1959行，但实际只有6行。这个估算偏差直接影响了优化器的索引选择逻辑：

• 当优化器认为过滤后的数据量很大时，它会觉得用idx_plot_created_at索引反向扫描是最优的：因为按created_at DESC顺序遍历，只要找到第一个满足fk_id条件的行就能返回（LIMIT 1），理论上成本极低，不用处理大量数据。
• 但实际情况是，符合条件的6行在created_at索引里的位置非常靠后，导致优化器需要扫描几十万行才能命中目标，这就造成了2.8秒的耗时。
• 而当你去掉ORDER BY和LIMIT时，优化器知道要返回所有符合条件的行，自然会选择fk_id上的索引，只扫6行，速度当然快。

为什么会出现估算偏差？大概率是你的plots表统计信息过时了——PostgreSQL的ANALYZE命令没有及时更新表的统计数据，导致优化器不知道这个特定fk_id值对应的实际行数这么少。

解决办法 #

1. 更新表统计信息（优先推荐） #

先执行这条命令，让PostgreSQL重新收集表的统计数据：

ANALYZE plots;

更新后，优化器会拿到准确的行数（6行），此时它会意识到：用fk_id索引取出所有6行，再按created_at排序取第一条的成本，远低于反向扫描created_at索引找目标行的成本，自然会选择更优的执行计划。

2. 创建复合索引（长期最优方案） #

如果这个查询是高频执行的，建议创建一个覆盖查询的复合索引：

CREATE INDEX idx_plot_fk_id_created_at ON plots (fk_id, created_at DESC);

这个索引可以让PostgreSQL直接定位到指定fk_id下最新的那一行，不需要扫描额外数据，也不需要排序，查询性能会达到最优（耗时应该在几毫秒级别）。

3. 强制指定索引（临时方案） #

如果更新统计信息后优化器还是没选对，可以用索引提示强制走fk_id的索引（假设fk_id的索引名为idx_plot_fk_id）：

SELECT id FROM plots INDEX (idx_plot_fk_id) 
WHERE fk_id='73a711a5-cb31-545d-b8d6-75c2a0e3ba9d' 
ORDER BY created_at DESC LIMIT 1;

不过这个方法属于硬编码，不推荐长期使用，还是优先更新统计信息或创建复合索引。

内容的提问来源于stack exchange，提问作者Tõnis M