PostgreSQL 14 停更前升级 17 / 18：pg_upgrade 只用了 2 秒，升完不 ANALYZE 的那段时间查询慢了 5 倍

下面的日期都取自 PostgreSQL 官网版本策略页（2026-10-31 核对）。社区对每个大版本支持 5 年，最后一个小版本发布后就不再修复。

升 17：--check 用时 0.45 s，同时报出两个阻断项：「Checking for reg* data types in user tables」和「Checking for incompatible "aclitem" data type」，并说明 aclitem 的内部格式在 PostgreSQL 16 改了。具体是哪张表哪一列，写在 pg_upgrade_output.d 下的 tables_using_reg.txt 和 tables_using_aclitem.txt 里：legacy_app 库的 app_hooks.fn（regproc）和 app_acl.acl（aclitem[]）。

升 18：新集群用默认参数 initdb，--check 0.06 s 就停了，只报一句「old cluster does not use data checksums but the new one does」。原因是 PG18 的 initdb 默认开启数据校验和，而老集群当年没开，pg_upgrade 要求两边一致。用 initdb --no-data-checksums 重建新集群后再 --check，才看到和升 17 一样的 reg* 和 aclitem 两个阻断项。

所以别指望 --check 一次列全所有问题：前面的检查失败，后面的不会执行。我们的做法是在源库上先跑一遍只读预检 SQL（下载区），把校验和、reg*、aclitem、扩展、扩展统计、复制槽、两阶段事务一次查清，再用新版本的 pg_upgrade --check 收尾。

每轮都从同一份停机状态的 PG14 副本开始，执行 sync 后计时 pg_upgrade 整条命令。数据量小、又在页缓存里，所以几种方式差距只有 1 秒左右；--copy 要把数据文件复制一遍，数据越大差距越大，--link 和 --swap 主要是元数据操作。

--link 的代价是回退：升级完成时，pg_upgrade 把老集群的 global/pg_control 改名为 pg_control.old，输出里写明「Because "link" mode was used, the old cluster cannot be safely started once the new cluster has been started」。我们试了一次，直接 pg_ctl start 老集群，报找不到 global/pg_control，起不来。用 --link 或 --swap，回滚方案就只能是升级前的备份或备库，不能指望老目录。

PG17 的 pg_upgrade 输出最后一段写着：「Optimizer statistics are not transferred by pg_upgrade」，并建议运行 vacuumdb --all --analyze-in-stages。启动新集群后查 pg_stats，public 下 0 行，pg_statistic_ext_data 也是 0，两张表的 reltuples 是 -1。

这时跑同一组查询（每条 3 次取中位数）。Q1 统计 vip 客户的已完成订单：PG14 上 Nested Loop，183.6 ms；PG17 无统计时 status='done' 估 19445 行、实际 4850231 行，计划变成 Bitmap Heap Scan + Hash Join，994 ms。Q3 按城市统计 10 月以来的订单：估 540129 行、实际 66210 行，从索引扫描变成并行全表扫描，166.7 ms。Q4 按 city + district 查：customers 估 1 行、实际每个并行进程 200 行，34.4 ms。只有 Q2（主键倒序取 50 条）没受影响。

跑 vacuumdb --all --analyze-in-stages，整条命令 0.72 s。它分三轮：先用统计目标 1 快速出一版（这一轮 33.6 ms），再用 10，最后用默认值。只跑完第一轮时，Q1 已经回到 146 ms，但估算还很粗（Q4 估 430、实际 10000）；三轮跑完，Q1 133 ms、Q3 65.5 ms、Q4 3.5 ms，估算和 PG14 基本一致。

很多升级方案里写着「升级后 autovacuum 会自动 analyze」。我们在刚升级的 PG17 上打开 autovacuum，把 autovacuum_naptime 调到 5 秒，什么都不写，等了 75 秒：n_mod_since_analyze 是 0，last_autoanalyze 为空，pg_stats 仍是 0 行。

然后在 customers 和 orders 各 UPDATE 100 行（12:01:39），1–2 秒内两张表都自动 analyze 了（12:01:40、12:01:41），pg_stats 变成 10 行。autovacuum 判断要不要 analyze，看的是上次 analyze 以来改了多少行，而不是有没有统计。

所以写入频繁的表，统计很快会被补上；维表、字典表、历史归档表、只在月底跑报表的表，可能很久都没有统计，正好是那些大 JOIN 和报表查询会用到的表。默认 naptime 是 1 分钟，就算是写入频繁的表，也有一段窗口在用错误的计划跑。

PostgreSQL 18 的发布说明写明：pg_upgrade 会保留优化器统计，但扩展统计（CREATE STATISTICS）不保留；同时新增 pg_upgrade --no-statistics、--swap，以及 vacuumdb --missing-stats-only。

实测一致：用 --swap 升到 18.6 后，pg_stats 有 10 行（和升级前一样），pg_statistic_ext_data 是 0，reltuples 也保留了。Q1、Q3 的计划和估算与 PG14 相同（Q1 估 27716、实际 24262）。Q4 里 customers 按 city + district 过滤，估算从 399 掉到 8（实际 400），连接估算从 9975 掉到 200（实际 10000）。这次 Q4 碰巧还是同一个计划，耗时 3.9 ms；在我们之前那篇扩展统计的测试里，同样的低估让计划变成了 Nested Loop。

pg_upgrade 18 的输出建议先跑 vacuumdb --all --analyze-in-stages --missing-stats-only，再跑 vacuumdb --all --analyze-only。前一条用时 0.20 s，只 analyze 了有扩展统计的 customers（orders 的 last_analyze 仍为空），Q4 估算回到 399；后一条完整 analyze 0.46 s。

目标版本：我们倾向直接上 18。支持期到 2030-11-14，比 17 多一年；更重要的是升级后普通统计还在，ANALYZE 之前那段「计划全错」的窗口小得多。代价是两个要提前处理的点：新集群 initdb 的校验和要和老集群一致，有扩展统计的表升级后要补一次 --missing-stats-only。

停机窗口：按「pg_upgrade + ANALYZE + 回归 SQL」三段估，而不是只看 pg_upgrade。第三段是把核心查询（报表、大 JOIN、按相关列过滤的查询）拿出来跑一遍 EXPLAIN，对比升级前保存的计划。

回滚：用 --link 或 --swap，就不能指望老目录还能起来，要在升级前确认最近一次备份能恢复（可以参考下面链接里的 PostgreSQL 备份恢复演练脚本），或者保留一个不参与升级的备库。

预检 SQL 每条语句都是 SELECT，在 PG 14.24 上测过：legacy_app 库查出 regproc 列和 aclitem[] 列各 1 个，upg_lab 库查出 1 个扩展统计 customers_city_district_stx。每个业务库各跑一次，把输出发给我们也可以。

一键脚本会在你指定的目录里新建 3 个集群，只监听本机 Unix socket，用默认 500 万行时约需 4 GB 磁盘，在我们的测试机上完整跑完 39 秒。只能在测试机上用。