Postgres 11.16 RDS只读副本升级为独立库后的性能异常问询

将Postgres 11.16 RDS集群的只读副本（RR）升级为独立数据库后，该实例性能出现显著下降。对比生产只读副本（PROD）与升级后的RR执行EXPLAIN的结果，发现RR性能下降了40倍。AWS确认环境无变更，因此开始排查Postgres内部行为。

以下为EXPLAIN查询结果汇总（注意启动后实际总耗时的40倍增幅）：

约一半的性能损失在24小时后恢复。现咨询：将只读副本升级为独立数据库是否存在副作用？即Postgres是否需要在变更后执行额外的整理操作？

• 只读副本转独立实例的核心副作用：统计信息滞后与缓存重置
  只读副本原本同步主库数据，其统计信息（pg_statistics）多来自主库复制，转成独立实例后，Postgres不会立刻自动更新这些统计数据。优化器依赖过时统计信息时，可能选择低效执行计划（比如放弃索引走全表扫描），直接导致性能暴跌。另外，转独立后实例的共享缓存（shared_buffers）会被清空，需要重新加载数据，这也是初期性能差的关键原因——24小时后部分恢复，基本是缓存逐步预热、自动统计信息更新任务生效的结果。

• 建议执行的额外整理操作

  1. 手动更新统计信息：立即执行ANALYZE VERBOSE;（全库范围），或针对慢查询涉及的表单独执行ANALYZE <表名>;，强制Postgres重新收集表的统计数据，让优化器生成精准的执行计划。
  2. 主动预热缓存：对核心业务查询手动执行几次，将常用数据提前加载到shared_buffers，避免依赖业务流量缓慢预热。
  3. 检查并修复索引：通过SELECT * FROM pg_stat_user_indexes WHERE idx_scan = 0;排查未被使用的冗余索引；若存在索引碎片，执行REINDEX CONCURRENTLY <索引名>;在线修复（避免锁表）。
  4. 监控autovacuum运行状态：转独立后实例从只读变为可写，autovacuum需要处理新写入产生的死元组。可通过SELECT * FROM pg_stat_activity WHERE query LIKE '%autovacuum%';确认进程正常，防止死元组堆积拖慢查询。

• 关于24小时后部分恢复的原因
  Postgres默认autovacuum会在表数据变更率达到阈值（由autovacuum_analyze_scale_factor和autovacuum_analyze_threshold控制）时触发ANALYZE，24小时内大概率完成了一轮统计信息更新；同时业务流量持续访问，逐步将热点数据加载到缓存，因此性能恢复了一半。但如果统计信息更新不彻底，或缓存未完全覆盖常用数据，性能仍会低于原只读副本水平。

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