PostgreSQL索引优化实战：从慢查询到高效索引设计

1. 问题背景：当PostgreSQL查询突然变慢

上周五临下班前，我正准备收工，突然接到业务方报警——核心报表页面的加载时间从平时的200ms飙升到8秒。作为团队里负责数据库优化的"救火队员"，我立刻打开pgAdmin连上生产环境。通过pg_stat_activity视图，很快锁定了那条罪魁祸首的SQL：

sql复制SELECT * FROM order_details 
WHERE user_id = 12345 
AND create_time BETWEEN '2023-01-01' AND '2023-12-31'
ORDER BY amount DESC
LIMIT 100;

这条看似简单的查询，在测试环境只要50ms就能返回，生产环境却要8秒。更诡异的是——这个查询三个月前还是毫秒级响应。接下来12小时的排查过程，让我对PostgreSQL索引有了全新的认识。

2. 第一重排查：索引是否存在？

2.1 基础检查：索引列表确认

我的第一反应是检查索引是否存在。通过\d order_details查看表结构，确实看到了期望的索引：

sql复制CREATE INDEX idx_order_details_user ON order_details(user_id);
CREATE INDEX idx_order_details_createtime ON order_details(create_time);

但EXPLAIN ANALYZE的结果却显示Seq Scan（全表扫描）：

code复制QUERY PLAN
-----------------------------------------------------------
Limit (cost=10000000000.00..10000000001.20 rows=100 width=68)
  -> Seq Scan on order_details (cost=10000000000.00..10000000000.00 rows=1000 width=68)
        Filter: ((user_id = 12345) AND (create_time >= '2023-01-01'::date) AND (create_time <= '2023-12-31'::date))

2.2 为什么有索引却不用？

这里暴露了新手常见的误解：PostgreSQL不是有索引就一定会用。通过SET enable_seqscan = off强制禁用全表扫描后，执行计划变成了：

code复制QUERY PLAN
------------------------------------------------------------------------------------
Limit (cost=0.42..12.64 rows=100 width=68)
  -> Index Scan using idx_order_details_user on order_details (cost=0.42..120.64 rows=1000 width=68)
        Index Cond: (user_id = 12345)
        Filter: ((create_time >= '2023-01-01'::date) AND (create_time <= '2023-12-31'::date))

这说明优化器认为：对于这个查询条件，全表扫描比走索引更快。原因有二：

1. 表数据量从3个月前的1万条增长到了50万条
2. user_id=12345的记录占比达到30%，索引选择性太低

3. 第二重排查：复合索引设计

3.1 创建复合索引的尝试

既然单列索引效果不好，我尝试创建复合索引：

sql复制CREATE INDEX idx_order_details_user_createtime 
ON order_details(user_id, create_time);

再次EXPLAIN ANALYZE：

code复制QUERY PLAN
------------------------------------------------------------------------------------
Limit (cost=0.42..8.44 rows=100 width=68)
  -> Index Scan using idx_order_details_user_createtime on order_details (cost=0.42..80.44 rows=1000 width=68)
        Index Cond: ((user_id = 12345) AND (create_time >= '2023-01-01'::date) AND (create_time <= '2023-12-31'::date))

查询时间降到200ms，看起来问题解决了？但业务反馈：不同用户的查询性能差异极大。某些user_id的查询仍然需要3秒以上。

3.2 复合索引的排序陷阱

通过EXPLAIN (ANALYZE, BUFFERS)发现关键问题：

code复制QUERY PLAN
------------------------------------------------------------------------------------
Limit (cost=0.42..12.64 rows=100 width=68)
  -> Index Scan using idx_order_details_user_createtime on order_details (cost=0.42..120.64 rows=1000 width=68)
        Index Cond: ((user_id = 12345) AND (create_time >= '2023-01-01'::date) AND (create_time <= '2023-12-31'::date))
        Buffers: shared hit=423

问题出在ORDER BY amount DESC——数据库需要先通过索引找到所有符合条件的行，然后额外排序。对于返回行数多的user_id，这个排序操作非常耗时。

4. 第三重排查：包含排序的复合索引

4.1 创建包含排序列的索引

终极解决方案是创建包含所有查询条件的索引：

sql复制CREATE INDEX idx_order_details_covering 
ON order_details(user_id, create_time, amount DESC);

这个索引完全覆盖了查询条件（WHERE和ORDER BY），执行计划变为：

code复制QUERY PLAN
------------------------------------------------------------------------------------
Limit (cost=0.42..4.44 rows=100 width=68)
  -> Index Only Scan using idx_order_details_covering on order_details (cost=0.42..40.44 rows=1000 width=68)
        Index Cond: ((user_id = 12345) AND (create_time >= '2023-01-01'::date) AND (create_time <= '2023-12-31'::date))

查询时间稳定在50ms以内，且不同user_id的性能差异小于10%。

4.2 索引膨胀的隐藏问题

本以为大功告成，但一周后同样的问题再次出现。通过pg_stat_all_indexes发现：

code复制relname       | indexrelname                  | idx_scan | idx_tup_read | idx_tup_fetch
--------------+-------------------------------+----------+--------------+--------------
order_details | idx_order_details_covering    | 89234    | 12567890     | 125678

索引扫描次数与元组读取数比例异常。运行VACUUM ANALYZE order_details后性能恢复，说明遇到了索引膨胀问题。

5. 长效解决方案：监控与维护

5.1 创建自动化监控脚本

将以下查询加入监控系统：

sql复制SELECT
    schemaname || '.' || relname AS table,
    indexrelname AS index,
    pg_size_pretty(pg_relation_size(indexrelid)) AS index_size,
    idx_scan AS scans,
    idx_tup_read AS tuples_read,
    idx_tup_fetch AS tuples_fetched
FROM pg_stat_all_indexes
WHERE idx_scan > 0 
AND idx_tup_read::float / idx_scan > 10000;

5.2 定期维护策略

设置每周维护窗口执行：

bash复制# 重新构建膨胀严重的索引
REINDEX INDEX CONCURRENTLY idx_order_details_covering;

# 更新统计信息
VACUUM ANALYZE order_details;

# 清理旧数据（如有时间条件）
DELETE FROM order_details 
WHERE create_time < now() - interval '2 years';

6. 经验总结与避坑指南

1. 不要迷信单列索引：随着数据量增长，原本有效的单列索引可能突然失效。复合索引的设计要考虑WHERE条件和ORDER BY的组合。

2. 警惕高选择性字段：当某个条件的匹配率超过5%时，PostgreSQL可能选择全表扫描。可以通过SET enable_seqscan = off临时验证是否是优化器选择问题。

3. 索引排序方向很重要：DESC排序的查询需要对应DESC的索引，混合排序方向会导致性能下降。

4. 监控索引使用率：通过pg_stat_all_indexes定期检查索引的实际使用效果，删除从未使用或效率低下的索引。

5. 注意索引膨胀：频繁更新的表会导致索引膨胀，表现为索引大小持续增长但查询性能下降。需要定期VACUUM或REINDEX。

这次事故让我深刻体会到：数据库优化不是一劳永逸的工作。随着业务发展，需要持续监控和调整索引策略。现在我们的监控系统增加了索引效率看板，类似问题再未发生过。