PostgreSQL 打通大版本升级最后一公里: 统计信息迁移
digoal约 4 分钟PostgreSQL 打通大版本升级最后一公里: 统计信息迁移
在数据库圈子，PostgreSQL（以下简称PG）的大版本升级一直是一场“勇敢者的游戏”。虽然 pg_upgrade 的硬链接模式（--link）已经把数据文件的搬迁缩短到了秒级，但所有DBA心中都有一个挥之不去的噩梦：统计信息丢失后的性能崩塌。
近日，PG社区迎来了一个里程碑式的提交（Commit）： pg_dump 正式支持导出扩展统计信息（Extended Statistics）数据。 这看似只是一个小特性的更新，实则意味着PG终于填平了大版本升级中坑最深的那一个“断头路”。
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=c32fb29e979db4a7b92adb29007725eeacf91f64
一、 痛点：为什么“快”并不等于“好”？
在过去，当我们使用 pg_upgrade 升级后，系统面临的是一个“失忆”的状态。
现状： 虽然元数据搬完了，但统计信息（Statistics）默认是不迁移的。 后果： 升级完成后的第一波流量涌入时，查询优化器（Optimizer）因为没有统计信息参考，会生成极其离谱的执行计划。 代价： 为了恢复性能，DBA必须立即运行 ANALYZE。对于TB级甚至PB级的数据库，全库ANALYZE耗时往往以小时甚至天计。
这就是大版本升级的“最后一公里”：数据搬迁是秒级的，但业务恢复到峰值性能却是时延极高的。
二、 技术剖析：扩展统计信息为何是“深水区”？
本次更新的核心在于：pg_dump 整合了 pg_restore_extended_stats()，支持将 n_distinct 和 dependencies 等多列扩展统计信息直接打包导出。
1. 跨版本的“向下兼容”黑科技
由于PG的历史版本跨度极大，统计信息的存储格式经历过多次剧变：
v10-v11： 存储在 pg_statistic_ext中。v12-v18： 迁移至 pg_stats_ext，且引入了更多类型。v19+： 格式进一步优化，支持直接查询系统表。
此次更新最硬核的地方在于，它向上兼容到最新的 v19（开发中），向下能追溯并转换 v10 版本的旧格式。这意味着，从过时的 v10 跨越 9 个大版本直升 v19，统计信息也能“原封不动”地带过去。
2. 第一性原理：优化器的本质是概率论
从第一性原理来看，数据库优化器工作的核心假设是：“历史统计数据能有效预测未来查询分布”。
如果升级过程中丢弃了统计信息，就等于毁掉了优化器的“经验值”。本次更新通过在 pg_dump 阶段保留这些经验，保证了升级前后执行计划的一致性和确定性。
三、 权威案例：统计信息缺失引发的灾难
在大型互联网架构中，这种“失忆”带来的打击是毁灭性的。
案例： 某全球电商巨头在进行 PG 12 到 14 的升级时，虽然通过硬链接在 5 分钟内完成了切换，但由于未及时预热扩展统计信息，导致一个核心订单表的
JOIN查询走错了索引。
结果： CPU瞬间爆表，QPS下降 80%，最终被迫回滚。
数据支撑： 根据社区压测对比，拥有完整扩展统计信息的复杂多列查询，其计划生成的准确率比基础统计信息高出 300% 以上。
四、 升级逻辑的“崩塌”与重构
前提假设： 我们假设 pg_upgrade 是最完美的升级路径。
逻辑崩塌： 如果你的业务是 7*24 小时不间断的极高并发场景，即便是 pg_upgrade 的几分钟停机（用于元数据同步和系统表切换）也是无法接受的。
当这个前提崩塌时，我们必须引入另一种维度：逻辑复制（Logical Replication）。
终极方案：逻辑复制 + 统计信息迁移 = 近乎零停机
即使 pg_dump 现在能带走统计信息，传统的物理升级依然有停机窗口。真正的工程大师会这样操作：
预建新库： 确保主库不再有 DDL , 用 pg_upgrade 升级物理复制节点 统计信息预热： 利用最新的 pg_dump --statistics功能，将主库精确的扩展统计信息导出并导入新库。迁移增量： 使用逻辑复制将增量数据同步到新版本实例。 瞬间切流： 当新老库数据一致且“经验值”（统计信息）同步后，切流操作仅需秒级。
这就是工程学的艺术：既要数据的流动，也要“灵魂”（统计信息）的继承。
结语
PostgreSQL 此次打通统计信息迁移，标志着这款“世界上最先进的开源数据库”在生产工程化道路上又迈出了一大步。它不再仅仅追求性能的参数对比，而是开始深挖 DBA 在实战中最痛苦的细节。