PostgreSQL主库执行ANALYZE后备库last_analyze为空且查询变慢咨询

备库last_analyze字段无值是预期行为 #

这是PostgreSQL的标准设计，不属于异常：

• pg_stat_user_tables中的last_analyze、last_vacuum、seq_scan等字段属于节点本地统计状态数据，仅记录当前节点自身执行的操作记录，不会通过流复制同步
• 主库执行ANALYZE生成的优化器依赖的统计信息（存储在pg_statistic系统表中）会被写入WAL日志同步到备库，完全不影响备库优化器生成执行计划
• 备库为只读模式，本身无法主动执行ANALYZE操作，因此该字段永远不会更新，无值属于正常现象

备库查询性能下降、索引失效的原因与解决方案 #

核心原因 #

主库ANALYZE生成的pg_statistic统计信息会同步到备库，备库优化器会直接使用这部分统计信息生成执行计划，出现计划退化通常是以下两类原因：

• 统计信息本身存在偏差：主库ANALYZE采样比例不足，生成的统计信息和实际数据分布差异较大，导致优化器行数估算错误，误判全表扫描成本低于索引扫描
• 主备参数配置不一致：random_page_cost、effective_cache_size、work_mem等影响执行计划成本计算的参数主备配置不同，主库配置下最优的索引扫描方案，在备库的成本计算中优先级低于全表扫描

解决方案 #

• 第一步先核对主备执行计划相关参数是否完全一致，重点检查以下参数：
  • random_page_cost
  • seq_page_cost
  • effective_cache_size
  • work_mem
• 如果参数无差异，针对出问题的表调高ANALYZE采样比例，重新生成统计信息：

  -- 针对指定表的字段调高采样比例，可根据表大小调整到1000~10000之间
  ALTER TABLE 你的表名 ALTER COLUMN 对应列名 SET STATISTICS 1000;
  -- 主库重新执行ANALYZE，生成的统计信息会自动同步到备库
  ANALYZE 你的表名;
  

• 临时应急场景可以调低备库的random_page_cost参数（比如调整为1.1，匹配SSD磁盘的实际随机IO成本），让优化器更倾向于选择索引扫描。

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