ORDER BY未使用已创建的feed_event_date_index索引问题排查

原因分析 #

• 数据量过小：PostgreSQL优化器会计算不同执行计划的成本。你的表仅1000条记录，全表扫描后在内存快速排序（仅消耗26kB内存）的开销，远低于通过索引定位每条数据再回表读取其他列的成本，因此优化器选择了更高效的全表扫描。
• 索引未覆盖查询需求：查询select *需要返回所有列，但feed_event_date_index仅包含event_date列。走该索引后，数据库需额外回表（通过主键查找剩余列），这增加了额外开销，优化器判断这种方式不如直接全表扫描划算。

解决办法 #

1. 临时强制使用索引（仅用于调试） #

可以用索引提示强制优化器选择指定索引，验证索引是否能正常工作：

explain analyze select * from feed order by event_date desc index feed_event_date_index;

注意：这种方式会绕过优化器的成本判断，当数据量或表结构变化后可能导致性能下降，不适合生产环境长期使用。

2. 创建覆盖索引（生产环境推荐） #

如果业务上经常需要按event_date降序查询全列，创建包含所有需要列的覆盖索引，避免回表开销：

-- PostgreSQL 11+支持INCLUDE子句，可添加除event_date外的所有列
create index feed_event_date_covering_idx on feed (event_date desc) include (id, /* 此处列出表中其他所有列 */);

这样查询时可直接从索引中获取所有数据，优化器会优先选择该索引。

3. 调整优化器成本参数（谨慎操作） #

临时调整会话级参数，让优化器认为全表扫描成本更高：

-- 降低索引回表的成本权重
set random_page_cost = 1.1;
-- 提高全表扫描的成本权重
set seq_page_cost = 2;

执行查询后记得恢复默认值：

set random_page_cost = 4;
set seq_page_cost = 1;

这种方式会影响当前会话的所有查询计划，不建议全局修改，仅用于临时测试。

4. 等待数据量自然增长 #

当表中数据量达到几万条以上时，全表扫描的成本会显著上升，优化器会自动切换为使用索引。当前1000条数据的场景下，全表扫描的性能已经足够优秀（执行时间仅0.161ms），没必要强制走索引。

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