PostgreSQL查询规划器为何加LIMIT 1时选用非WHERE子句索引？

核心逻辑：基于成本估算的计划选择 #

PostgreSQL查询规划器的核心目标是选择它认为成本最低的执行计划，而成本判断完全依赖表的统计信息和内置的成本模型。针对你的场景，两种查询的计划选择差异可以拆解为：

1. 无LIMIT 1时的计划（ContactOID索引） #

当查询需要返回所有ContactOID = 19446的行时：

• 执行路径：通过ContactOID索引直接定位所有匹配行，取出FeeDate后完成排序（由于实际耗时仅0.052ms，说明匹配行数极少，排序成本可以忽略）。
• 规划器判断：这种路径的总成本远低于遍历FeeDate索引找匹配行，因此优先选择ContactOID索引。

2. 带LIMIT 1时的计划（FeeDate索引） #

添加LIMIT 1后，查询只需要返回符合条件的最小FeeDate行，规划器会评估两种可行路径：

路径A：ContactOID索引 + 排序

• 流程：用ContactOID索引取出所有匹配行，排序后取第一行。
• 成本估算：如果规划器通过统计信息判断ContactOID = 19446的匹配行数较多，会高估排序的开销，导致这条路径的估算成本上升。

路径B：FeeDate索引顺序扫描

• 流程：按FeeDate从小到大遍历索引，每一行检查ContactOID = 19446是否成立，找到第一个匹配行就停止。
• 成本估算：规划器默认假设，这种“顺序扫描+条件校验”的方式不需要遍历太多行就能找到目标，因此估算的成本比路径A更低。

实际偏差的根源 #

你遇到的执行时间暴涨问题，本质是规划器的估算和实际数据分布不匹配：

• ContactOID = 19446对应的行的FeeDate可能处于索引的极靠后位置，导致规划器需要遍历绝大部分FeeDate索引条目才找到匹配行，累积的IO和计算成本远超预期。
• 统计信息缺失：PostgreSQL的统计信息没有记录ContactOID和FeeDate的关联分布（比如某个ContactOID对应的FeeDate集中在哪个区间），导致规划器的成本判断出现错误。

验证与优化方案 #

• 最优解：创建复合索引：你提到的(ContactOID, FeeDate)复合索引可以直接定位目标行，且行数据已经按FeeDate排序，LIMIT 1时直接返回第一行，完全规避两种路径的缺点。
• 临时方案：强制指定索引（不推荐，依赖统计信息稳定性）：

  SELECT "FeeDate" 
  FROM "FEE" 
  WHERE "ContactOID" = 19446 
  ORDER BY "FeeDate" 
  LIMIT 1 
  INDEX USING "ContactOID_idx"; -- 替换为你的ContactOID索引名
  

• 更新统计信息：执行ANALYZE "FEE";让规划器获取更准确的数据分布，可能纠正错误的成本估算。

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