谈国平前阵子一个老项目突然报了个线上告警，一个Postgres查询接口的P99耗时从300ms一路涨到了3秒多。翻了一圈慢查询日志，发现罪魁祸首是一条再普通不过的SQL，表也就一百多万行，但每次查询都在做全表扫描。我把执行计划喂给DeepSeek，让它从读取效率的角度帮我拆解，结果它给出的几个方向，基本覆盖了Postgres查询性能问题的绝大部分场景。这篇文章就是把这次和后续几轮排查的经验整理出来，聊聊Postgres查询里的读取效率问题到底出在哪、怎么定位、怎么优化，希望对被慢查询折磨的运维和开发朋友有点帮助。
1. 先搞清楚：读取效率差，到底差在哪里
1.1 慢在“读得多”，而不是“算得慢”
很多人在定位Postgres慢查询时，第一反应是去看CPU占用、看SQL写得有多复杂，但实际上绝大多数读取效率问题的根源，都可以归结为一句话：数据库读了太多它不该读的数据。
Postgres的数据是按页存储的，默认8KB一页。哪怕你只需要一行记录，数据库也得把包含这一行的整页数据读进内存。如果查询走了全表扫描（Seq Scan），那就是把表的所有数据页从头到尾翻一遍；如果走索引扫描，则可以精确定位到少数几页，读取量差出几个数量级。
这里可以打个比方：在一本没有目录的字典里查一个词，你只能一页一页翻；有目录的话，先翻到对应页码，直接取词就行。全表扫描是在翻整本字典，索引扫描是查目录。读取效率问题的本质，就是“减少必须读的页数”。
1.2 数据是怎么被“读”出来的：三层缓存链路
一条查询要把数据读出来，会经过三层缓存或存储：
- 磁盘IO层：数据不在任何内存里，必须从磁盘加载。这是最慢的环节，机械硬盘一次随机读要好几毫秒，SSD也要几十到几百微秒。
- Postgres共享缓冲区（shared_buffers）：这是Postgres自身管理的内存缓存，默认128MB起，命中这里的读操作非常快。
- 操作系统页缓存：即使shared_buffers没命中，OS的页缓存里可能还有一份，也不算太慢。
所以你会观察到这种现象：一条SQL第一次跑很慢，第二次跑就快了，这就是缓存生效。而读取效率差的查询，往往有两个特征：要么每次都从磁盘捞数据，把缓存命中率拉得很低；要么每次都把大量不需要的数据页捞上来，把整个缓存都污染了，拖累其他查询。
1.3 DeepSeek在定位阶段能帮你做什么
我习惯把DeepSeek当成一个“执行计划陪练”。看不懂的EXPLAIN输出，直接贴给它；拿不准该建什么索引，把建表语句和查询特征发给它，让它先给一版建议，我再结合实际执行结果判断。
印象最深的一次，我把一条带了好几个LEFT JOIN的报表查询丢给它，它很快指出WHERE条件里对右表字段的过滤会让LEFT JOIN退化成INNER JOIN语义，建议我检查驱动表选择。虽然Postgres优化器一般能处理这种改写，但这个提醒让我专门去看了执行计划里的Join顺序，最后还真发现顺序跟我想的完全不一样。
不过要泼一盆冷水：DeepSeek的SQL优化建议只能当参考方向，绝对不能照单全收。同样的语句在不同版本、不同数据分布下的最佳方案可能完全不同，最终一定要用真实的EXPLAIN ANALYZE结果来验证。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 定位问题：慢查询日志与EXPLAIN ANALYZE
2.1 先把慢查询日志打开
如果你现在还不知道线上哪些查询慢，第一步不是优化，是“装监控”。Postgres的慢查询日志是最直接的入口，在postgresql.conf里设置：
code复制log_min_duration_statement = 1000
log_destination = 'stderr'
logging_collector = on
log_min_duration_statement的单位是毫秒，设成1000表示超过1秒的语句都会记录。不想改文件的话，可以动态设置：
sql复制ALTER SYSTEM SET log_min_duration_statement = 1000;
SELECT pg_reload_conf();
ALTER SYSTEM会把配置写进postgresql.auto.conf，reload之后立即生效，不需要重启。有个小坑：如果把这个值设成0，会记录所有语句，生产环境日志量会非常恐怖，磁盘很快写满，别这么干。
除了日志，强烈建议开启pg_stat_statements扩展，它会把SQL按模板聚合，直接给你看每条语句的总耗时、调用次数、平均耗时、共享缓冲区命中情况。安装和查询都很简单：
sql复制CREATE EXTENSION IF NOT EXISTS pg_stat_statements;
SELECT query, calls, total_exec_time, mean_exec_time, shared_blks_read
FROM pg_stat_statements
ORDER BY total_exec_time DESC
LIMIT 10;
这个视图比翻日志高效太多，一眼就能看出哪些SQL是真正的“耗时大户”，我每次排查读取效率问题都是从这里起步的。
2.2 读懂EXPLAIN ANALYZE的关键指标
拿到可疑SQL之后，下一步是看执行计划。我习惯用带BUFFERS的完整版本：
sql复制EXPLAIN (ANALYZE, BUFFERS, TIMING ON)
SELECT o.id, o.amount, u.name
FROM orders o
JOIN users u ON u.id = o.user_id
WHERE o.status = 'paid'
AND o.created_at >= '2024-01-01'
ORDER BY o.created_at DESC
LIMIT 20;
输出里重点看四个东西：
- 最底层节点是不是Seq Scan。如果是，而且它过滤掉的行数比例很高，那就是典型的读取浪费。
- actual rows和estimated rows的偏差。偏差超过一个数量级，基本可以断定统计信息过期，优化器选错了计划。
- Buffers: shared hit / read。read的数字越大，说明从磁盘读的页越多，这是读取效率差的直接证据。
- 每个节点的Execution Time。找出耗时最大的节点，优化就围绕它进行。
2.3 让DeepSeek帮你解读执行计划
直接把上面这段执行计划文本贴给DeepSeek，然后问几个具体问题：这个计划里最大的瓶颈是什么？哪个节点最可能造成读取放大？如果要加索引，加在哪个表的哪个列上更合理？
实测下来，它能把Seq Scan、Hash Join、Sort这些节点概念拆得很清楚，对没系统学过执行计划的新手来说是个很好的陪练。但有个经验要分享：它给的索引建议有时会忽略复合索引的列顺序，你得自己懂一点索引原理，不能全盘照收。最好在对话里带上你的Postgres版本、表数据量、WHERE条件里每个字段的选择性，信息越全，建议越靠谱。
3. 索引策略：提升读取效率的第一生产力
3.1 索引失效的典型场景
这里列几个我在实战里反复踩过的坑：
- 对索引列套函数。比如WHERE upper(email) = 'AAA@EXAMPLE.COM'，普通B-tree索引直接失效。解决办法是建表达式索引：CREATE INDEX ON users (upper(email))，或者干脆统一存小写。
- 隐式类型转换。字段是varchar，查询参数传的是数字，或者反过来，Postgres很可能放弃索引扫描。检查一下字段类型和参数类型是否一致，类型不匹配时要显式转换。
- LIKE前置通配符。LIKE '%abc'走不了普通B-tree索引，LIKE 'abc%'可以。前导通配的模糊搜索，建议用pg_trgm扩展或者全文检索。
- OR条件。两个条件各自有索引，但优化器可能还是选全表扫描。遇到这种情况，改成UNION ALL通常更稳定。
3.2 复合索引的列顺序：不是随便排的
这是我最想让新手记住的一点。
sql复制CREATE INDEX idx_orders_status_created ON orders (status, created_at DESC);
和
sql复制CREATE INDEX idx_orders_created_status ON orders (created_at DESC, status);
对于查询WHERE status = 'paid' AND created_at >= '2024-01-01' ORDER BY created_at DESC，前者是完美契合的，后者基本只能用到一半。
原因是B-tree索引按字典序组织，只能高效利用“最左前缀”。等值条件（=）的列放到前面，可以精确锁定范围；范围条件（>、<、BETWEEN、ORDER BY）放到后面，用索引里剩余的部分去缩小范围。反过来，范围条件在前，后面的列就无法继续参与索引过滤了。
3.3 覆盖索引：少回表就是省IO
索引扫描虽然比全表扫描快，但普通索引扫描拿到行指针后，还得回表去取其他列，这个动作叫Heap Fetch。回表次数一多，读取效率照样上不去。
Postgres支持Index-Only Scan，条件是索引列包含查询需要的所有字段。如果某类查询只需要少数几列，可以这么建：
sql复制CREATE INDEX idx_orders_status_created ON orders(status, created_at DESC) INCLUDE (amount);
这样SELECT amount FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 20就能直接在索引页里拿数据，不需要回表。注意INCLUDE列不参与索引排序和过滤，只是负责“捎带”数据，别把大字段塞进去，否则索引会膨胀得很厉害。
4. 查询语句层面的优化实践
4.1 深分页问题：LIMIT OFFSET是读取效率杀手
LIMIT 20 OFFSET 100000看起来没什么，但Postgres的执行方式是把前100020行全部读出来，再丢掉前十万行。页数越深，读取量越大，耗时越长。
我处理过最夸张的一个分页接口，翻到第500页时，单次查询要读几万个数据页，耗时十几秒。解决办法是把偏移分页改成游标分页（keyset pagination）：
sql复制-- 传统方式：越翻越慢
SELECT * FROM orders ORDER BY id DESC LIMIT 20 OFFSET 400;
-- 游标方式：读取量恒定
SELECT * FROM orders
WHERE id < 400
ORDER BY id DESC
LIMIT 20;
游标分页不管翻多深，都只读一页数据，IO开销恒定。前提是排序字段有唯一性，用(id)或者(created_at, id)组合都行。缺点是没法直接跳页，但对大多数App的“下拉加载更多”场景来说完全够用。
4.2 JOIN、IN、EXISTS怎么选
IN和EXISTS在Postgres里通常都会被优化成semi-join，性能差别不大。真正的坑是IN后面跟一个特别大的值列表，几千上万个参数，解析成本和计划成本都会飙升，甚至可能超出参数上限直接报错——这就是网上经常搜到“in查询语句报错”的常见原因之一。
遇到大列表，我一般建议拆成多次查询，或者先导入临时表再JOIN。对万级以上的列表，临时表方式尤其有效：
sql复制CREATE TEMP TABLE tmp_ids (id int PRIMARY KEY) ON COMMIT DROP;
INSERT INTO tmp_ids SELECT unnest($1::int[]);
SELECT o.* FROM orders o JOIN tmp_ids t ON t.id = o.id;
JOIN本身的优化，重点看两件事：JOIN列上有没有索引，以及统计信息准不准导致Hash Join退化。小表驱动大表是朴素经验，Postgres优化器一般会自己选，不太需要人为干预。
4.3 视图到底能不能加快查询速度
这个问题在搜索引擎里问的人特别多，答案很明确：普通视图不能，物化视图可以。
普通视图本质是一段SQL的宏。你在视图上查询时，Postgres会把视图定义展开，跟原查询合并后再做优化。它不会预存任何数据，该全表扫描还是全表扫描，跟直接写底层SQL没有性能差异。有时候看起来“变快了”，只是因为同样的SQL多跑了几次，缓存生效了。
物化视图则真的把查询结果落盘存起来了，查询它不需要重新执行底层SQL，适合计算结果很重、结果又不经常变的场景：
sql复制CREATE MATERIALIZED VIEW mv_monthly_sales AS
SELECT date_trunc('month', created_at) AS month, sum(amount) AS total
FROM orders
GROUP BY 1;
REFRESH MATERIALIZED VIEW mv_monthly_sales;
代价是数据不是实时的，需要手动刷新或定时刷新。一句话总结：普通视图不加速，物化视图用空间换时间。
4.4 去重查询怎么写才高效
“SQL语句去重查询”是搜索高频词。去重一般两种写法：SELECT DISTINCT和GROUP BY。结果通常一样，但GROUP BY在某些场景下更容易配合索引，尤其是先做了等值过滤再聚合时，执行计划会更干净。
如果要按某列去重并保留完整行，Postgres有个特别好用的DISTINCT ON：
sql复制SELECT DISTINCT ON (user_id) *
FROM orders
ORDER BY user_id, created_at DESC;
这个写法表示每个user_id取最新一条记录。user_id上有索引的话，配合ORDER BY可以走Index Scan，比自连接高效得多。注意DISTINCT ON的列必须出现在ORDER BY的最左侧，这是语法强制的，也是理解这个特性语义的关键。
5. 常见问题与排查技巧实录
5.1 问题排查速查表
整理一张覆盖我排查读取效率问题时最常遇到状况的表，方便直接对照：
| 症状 | 可能原因 | 解决方向 |
|---|---|---|
| 慢查询日志里一条都没有 | log_min_duration_statement没生效或设置过大 | ALTER SYSTEM设置后pg_reload_conf() |
| EXPLAIN里Seq Scan且过滤率高 | 缺索引或统计信息过期 | 加索引；执行ANALYZE更新统计 |
| 实际行数与预估行数差10倍以上 | 统计信息过旧或采样不准 | ANALYZE表；考虑加大default_statistics_target |
| Buffers: read数值很高 | 数据不在缓存，且扫描页数过多 | 优化索引减少扫描；评估shared_buffers配置 |
| 明明有索引却走全表扫描 | 条件写法导致索引失效或选择性太差 | 改写SQL；检查函数、隐式转换、OR条件 |
| 报错role "postgres" does not exist | 连接角色或认证问题 | 用正确角色连接psql -U postgres，或CREATE ROLE |
| IN列表报错 | 参数数量过多或类型不匹配 | 改临时表JOIN；检查参数类型一致性 |
| 视图查询还是很慢 | 普通视图不物化 | 改为物化视图或直接优化底层SQL |
5.2 几个实测心得与建议
第一，维护统计信息。很多读取效率问题不是SQL写错了，而是数据量变了但统计信息没跟上。Postgres的autovacuum默认开着，但对频繁变更的大表，做完大批量更新之后手动执行一次ANALYZE很值得。
第二，别盲目堆索引。每个索引都会拖慢写入和更新，还可能让优化器选错计划。我的习惯是：先看pg_stat_statements里的Top N查询，一次只加一两个索引，用EXPLAIN验证效果，确认有效再加下一个。
第三，work_mem别乱调。设太大，并行排序和Hash Join会把内存吃光，反而拖垮整个实例。建议从64MB起步，结合EXPLAIN里Sort和Hash节点的实际使用量去调整。
第四，如果项目里用的是Django、SQLAlchemy这类ORM，先别急着改SQL。ORM打印出来的底层语句才是排查对象，很多“ORM查询特别慢”的问题，本质是ORM生成的SQL走了全表扫描或者N+1查询，跟Postgres本身关系不大。把EXPLAIN的对象锁定在真实执行的语句上，方向就不会跑偏。
最后分享一个小技巧：排查慢查询时，先把执行计划里耗时最大的节点圈出来，所有优化只围绕它展开。Postgres的执行是树状流水线，上游节点的读取量直接决定下游的负担，把根上的读取浪费修掉，整条链路的耗时都会跟着降下来。这个思路我在让DeepSeek做总结时反复验证过，它列出的那批问题，最后基本都能归到“读太多、读太散、读太旧”这三类里。排查的时候按这个思路走，比东一榔头西一棒子要高效得多。