为何Django查询PostgreSQL热备库比主库慢？
嗨，这个现象确实有点反常识，我来帮你梳理下可能的原因和排查方向～
先明确你的核心场景：两台配置完全相同的服务器，跑着PostgreSQL热备主备架构——主库承担读写、生成WAL日志，备库只读、通过WAL日志同步数据。但出现了两个让人困惑的性能表现：
- Django直连主库执行查询，耗时约是备库本地查询的一半
- 在备库服务器上远程查询主库，速度居然比备库本地查询快一倍
下面是几个最可能的原因，以及对应的排查和优化思路：
1. 备库WAL回放与本地查询的IO资源竞争
热备模式下，备库会持续在后台回放主库发送的WAL日志，这个过程会占用大量磁盘IO资源。如果备库的磁盘IO带宽被WAL回放完全占满，本地查询请求就需要排队等待IO资源，自然耗时变长。
而主库虽然也在写WAL，但PostgreSQL对主库的读写IO调度做了针对性优化，且主库的写操作与查询操作的IO模式更均衡，不会出现单方向占满IO的情况。甚至当备库磁盘IO瓶颈足够严重时，哪怕加上远程访问的网络延迟，主库的查询速度还是会比备库本地快——因为主库的IO资源没被回放占用。
排查方法：
- 用
iostat -x 1监控备库的磁盘IO，查看%util是否长期接近100% - 执行
SELECT * FROM pg_stat_replication;和SELECT * FROM pg_stat_wal_receiver;，查看WAL回放的延迟和速度，确认是否存在持续高负载回放
优化方向：
- 条件允许的话，将备库的WAL目录和数据目录放在不同磁盘上，分离回放写IO与查询读IO
- 调整checkpoint参数：调大
checkpoint_completion_target（建议设为0.9），让checkpoint的IO更平滑，减少突发IO压力 - 适当增大
wal_buffers，降低WAL写入的频率
2. 主备统计信息不一致，导致查询计划差异
PostgreSQL的查询计划依赖表的统计信息，主库因为有频繁写入操作，自动统计信息收集（autovacuum）会定期更新这些数据，生成最优查询计划。但备库是只读的，默认情况下autovacuum可能不会主动更新统计信息（或更新频率极低），导致统计数据过时。
举个例子：主库知道某张表的某列选择性很高，会选择索引扫描；而备库的统计信息还是数月前的，误以为该列选择性低，就用了全表扫描——这直接导致查询耗时翻倍。
排查方法：
- 在主备上分别执行
EXPLAIN ANALYZE <你的慢查询语句>，对比两者的执行计划，重点看扫描方式（索引扫描/全表扫描）、行数预估、实际耗时 - 执行
SELECT relname, last_autovacuum, last_autoanalyze FROM pg_stat_user_tables;，确认备库的统计信息是否很久没更新
优化方向：
- 在备库手动执行
ANALYZE <表名>（或ANALYZE;全库更新），更新统计信息后再测试查询速度 - 调整备库的
autovacuum参数：确保autovacuum_enabled = on，并适当调小autoanalyze_threshold和autoanalyze_scale_factor，让备库更频繁地更新统计信息
3. 主备缓存命中率差异
主库因为有持续的读写业务，常用查询数据大概率已经被缓存到PostgreSQL的shared_buffers或操作系统页缓存里，查询时直接读缓存，速度很快。
但备库一直在回放WAL日志，这个过程会产生大量写操作，可能把缓存里的查询数据页挤出去。当你在备库本地查询时，需要从磁盘重新加载数据，耗时自然变长；而远程查询主库时，主库的缓存命中率高，直接读缓存返回，哪怕加上网络延迟，总耗时还是比备库本地快。
排查方法：
- 计算主备的缓存命中率：执行
SELECT (sum(heap_blks_hit) / (sum(heap_blks_hit) + sum(heap_blks_read))) * 100 AS cache_hit_rate FROM pg_stat_user_tables;，备库命中率如果低于90%，说明缓存问题严重 - 查看
pg_stat_bgwriter里的buffers_checkpoint、buffers_clean等字段，确认备库缓存是否被频繁清理
优化方向：
- 适当增大备库的
shared_buffers参数（建议设为服务器内存的25%-50%），让更多数据留在PostgreSQL缓存里 - 调整操作系统的
vm.swappiness参数，降低内存换出概率，保证操作系统页缓存的有效性
内容的提问来源于stack exchange，提问作者B.Adler
