长亮不灭前阵子接到一个迁移任务，需求只有一句话：把这套 PostgreSQL 从老云平台迁到新云平台，顺手把版本从 11 升到 15，做全量迁移，停机窗口给四个小时。做过的人都懂，越短的需求描述往往藏着越多的坑——跨云意味着网络边界、云厂商特性差异、权限模型不同；跨版本意味着默认行为变化、扩展兼容性、系统表结构差异。两者叠加，迁移就不再是简单的“导出再导入”，而是一场需要提前把风险摊开、逐步验证的工程。
这篇文章不打算写成官方文档式的操作手册，而是把我这次从问题排查到生产就绪的全过程拆开讲：哪些环节必须提前确认、哪些坑是跨云场景特有的、哪些报错看起来莫名其妙但根因其实很简单。如果你也在准备一次 PostgreSQL 跨云跨版本全量迁移，这篇文章应该能帮你少走不少弯路。
1. 这个任务到底难在哪：跨云跨版本的真实差别
1.1 跨云与跨版本，是两个叠加的变量
单说“跨版本迁移”，PostgreSQL 官方工具链其实做得相当成熟。pg_dump 从老版本导出、到新版本恢复，这在社区里是常规操作，版本差异通常不会造成太大障碍。单说“跨云迁移”，如果版本相同，那么用逻辑复制或者云厂商自带的迁移服务也能相对平滑地完成。但这两者叠加在一起，事情就变了味。
首先是网络层面的差异。两个云平台之间通常不能直接通过内网互通，要么借助公网、要么通过专线或中转机。带宽、延迟、丢包率、安全组规则，每一项都可能成为瓶颈。我在这次迁移里遇到的第一个问题就是源库所在的云平台限制了出方向带宽，导致导出文件传输时间远超预期，直接压缩了后续导入和验证的时间。
其次是云厂商对 PostgreSQL 的“魔改”程度不同。大部分云厂商的 RDS 产品都不是完全原版的 PostgreSQL，而是基于某个社区版本打了补丁、改了参数、限制了部分权限。比如源库是 A 云的老版本实例，里面用了超级用户权限创建了一堆扩展；到了 B 云的新实例上，你能拿到的账号可能根本就不是真正的超级用户，某些扩展也不允许安装。这些隐藏差异，直到导入报错的时候才会暴露。
再者是版本差异本身。PG 11 到 PG 15 隔着四个大版本，期间有不少行为变化：PG 13 开始支持增量排序和对等哈希连接，PG 14 在事务处理上做了不少优化，PG 15 则把 public schema 的默认权限改了——以前 public schema 对 PUBLIC 角色开放 CREATE 权限，PG 15 开始默认收紧了。如果你的应用依赖“任何用户都能在 public schema 里建表”这种老行为，迁移后可能直接出现权限不足的报错。
1.2 全量迁移的适用边界：什么时候不该硬扛
标题里写的是“全量迁移”，这里必须先把边界说清楚。全量迁移的意思是：在某个时间点把源库的全部数据一次性搬到目标库，期间业务停机或者转入只读模式，搬完之后切换应用连接。它不涉及增量同步，也没有持续复制的环节。
这种方案适合什么场景？业务允许几小时的停机窗口、数据量在可接受范围内、源库和目标库之间不需要长期保持同步。如果数据量达到 TB 级别、停机窗口只有十几分钟、或者业务要求迁移期间完全不停服，那全量迁移就不合适了，应该考虑逻辑复制、物理流复制加版本升级，或者引入专业的数据库同步工具。
我在这次项目里选择全量方案，是基于三个事实：第一，业务方确认可以接受周末凌晨四小时的停机；第二，数据盘总量约 300GB，按当时的带宽和导入速度估算，四小时虽然紧张但可行；第三，目标端是一个全新的云数据库实例，不需要和源库长期并行。如果这三个条件任何一个不满足，我都会重新评估方案。
1.3 先把停机时间算明白，别等切流了才发现窗口不够
停机时间不是只有“导出数据”这一块。完整的停机窗口应该包括：
- 导出耗时：取决于源库的 CPU、IO、网络带宽
- 传输耗时：取决于导出文件大小和网络带宽
- 导入耗时：取决于目标库的性能、并行度、数据分布
- 验证耗时：行数核对、抽样校验、应用冒烟测试
- 缓冲余量：应对突发问题的时间
我习惯在迁移方案文档里给每一项都写一个估算值和最坏情况值。比如导出预计 40 分钟，但最坏可能 90 分钟；如果所有环节的最坏情况加起来超过了停机窗口，那这个方案就不合格，必须提前优化。优化手段可以是：导出时用高压缩级别减小传输体积、导入时临时调大 maintenance_work_mem、把索引和约束的创建推迟到数据导入完成之后。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 动手前的“体检”：源库信息收集与版本差异盘点
2.1 源库体检清单：每一张表都要心里有数
迁移最忌讳的是“到了才看、错了才查”。我接到任务后做的第一件事不是写导出命令，而是把源库做了一次全面的“体检”。体检的核心是回答以下几个问题：
- 版本和平台信息：大版本、小版本、是否云厂商定制版
- 字符集与排序规则：数据库的 encoding、LC_COLLATE、LC_CTYPE
- 扩展依赖：装了哪些扩展、版本是多少
- 对象规模：总共有多少个 schema、多少个表、最大的 20 张表是哪些
- 序列状态：每个表的序列当前值、有没有发生过回绕
- 角色与权限：有哪些业务角色、owner 是谁、有没有特殊的默认权限
- 非默认参数：尤其是 old_snapshot_threshold、max_connections、shared_buffers 等
下面这几条 SQL 我几乎每次迁移都会跑一遍：
sql复制-- 版本信息
SELECT version();
-- 数据库字符集与排序规则
SELECT datname, pg_encoding_to_char(encoding), datcollate, datctype
FROM pg_database;
-- 已安装扩展
SELECT extname, extversion, n.nspname AS schema
FROM pg_extension e
JOIN pg_namespace n ON n.oid = e.extnamespace;
-- 占用空间最大的 20 张表
SELECT schemaname, tablename,
pg_size_pretty(pg_total_relation_size(schemaname || '.' || tablename)) AS total_size
FROM pg_tables
WHERE schemaname NOT IN ('pg_catalog', 'information_schema')
ORDER BY pg_total_relation_size(schemaname || '.' || tablename) DESC
LIMIT 20;
这些信息不仅仅是给自己看的，还要整理成文档发给目标云平台的 DBA 或技术支持。很多云厂商的实例参数、扩展支持情况，都需要提前确认。比如我要用的 pgcrypto 和 pgvector，在老云上是直接创建扩展就行，但新云上可能默认没有这个扩展插件，需要提工单开通，这个过程可能要等一两天。
2.2 PG 版本差异里最容易踩中的几个点
跨版本迁移最大的不确定性，来自 PostgreSQL 在多个大版本之间的默认行为变化。我不打算在这里罗列所有 changelog，只挑几个我实际遇到或真实观察到的问题。
第一是 public schema 权限变化。PG 15 开始，普通用户不再自动拥有 public schema 的 CREATE 权限。如果你的应用有多个数据库账号，并且某些账号需要自己建表、建视图，那么迁移到 PG 15 后可能报 permission denied for schema public。这个问题在恢复阶段不会暴露，往往是应用第一次写数据时才炸出来。
第二是默认参数变化。PostgreSQL 不同版本对 max_wal_size、checkpoint_completion_target、effective_cache_size 的默认值都有调整。如果目标库沿用默认参数，导入大批量数据时可能会出现检查点过于频繁、WAL 写入量大增的情况。导入阶段我通常会把 max_wal_size 临时调大，导入完成后再恢复。
第三是系统列和系统函数的差异。跨大版本后，某些依赖系统表结构的第三方工具可能失效，但这属于应用层问题，不在迁移本身范围内。
还有一点容易被忽略：如果源库的主版本是 11，而目标库是 15，那么 pg_dump 的版本建议使用目标端版本，或者使用一个高于源库版本的 pg_dump。PostgreSQL 官方保证新版本的 pg_dump 可以导出旧版本数据库的数据，但并不保证旧版本 pg_dump 导出的文件一定能被新版本完整恢复。实际操作中，我一般会用目标版本一致的客户端工具在源库执行导出，或者在中转机上安装目标版本的 PostgreSQL 客户端。
2.3 工具选型：为什么全量场景我还是首选 pg_dump / pg_restore
做 PostgreSQL 全量迁移，可选的路其实不少：pg_dump/pg_restore、pg_dumpall、物理备份恢复、云厂商自带迁移服务、第三方同步工具。我这次依然选了 pg_dump/pg_restore 组合，原因是它在这几个维度上最平衡。
- 跨版本兼容：pg_dump 支持从旧版本导出、到新版本恢复，这是逻辑备份天然的优势。物理备份则是严格的版本绑定，PG 11 的物理备份不能直接恢复到 PG 15，这条路直接排除。
- 可控性：导出内容可以选择 schema、表、数据、索引、权限，也可以排除某些对象。导入时可以手动控制顺序，先建结构再导数据最后建索引，这对压缩停机时间非常重要。
- 恢复粒度：pg_restore 支持按 section（pre-data / data / post-data）逐步恢复，也支持只恢复某一张表，排错和重试都很方便。
- 排错直观：一个对象一个命令，报错信息能直接定位到具体对象，比黑盒迁移服务更容易排查。
pg_dumpall 也有它的用处，但它是纯文本格式，不支持并行恢复，也不支持按对象选择性恢复。我通常只用它导出全局对象（角色、表空间、权限），也就是 pg_dumpall --globals-only，数据部分则不交给它。
云厂商自带的迁移服务适合什么场景？如果你和我一样，已经明确知道目标实例的版本、参数、扩展，并且希望少写几条命令，那迁移服务确实省事。但它的问题是：很多操作的内部执行逻辑不透明，一旦迁移中途报错，排错手段有限；而且部分云厂商的迁移工具不支持跨大版本或者需要额外开通权限，反而把事情搞复杂。
3. 完整迁移链路：导出、传输、导入三步走
3.1 导出阶段：并行、一致性和锁的平衡
导出阶段的目标，是在尽量短的时间里生成一份一致的、完整的逻辑备份。这里的关键词是“一致”。pg_dump 在默认情况下，导出开始时会开启一个可重复读事务，整个导出过程基于同一个快照，所以数据一致性是有保证的。不需要额外担心导出过程中源库还有写入会导致备份不一致——只要你能接受最终一致性，这个问题就不存在。
下一个问题是格式。我强烈建议使用自定义格式（-Fc），而不是纯 SQL 格式。自定义格式是压缩的、支持并行恢复、支持按需恢复单个对象。纯 SQL 格式虽然可读性好，但大库恢复时体验很差，一旦中断没法断点继续，只能从头再来。
我这次的导出命令大致是这样：
bash复制pg_dump -h <源库地址> -p 5432 -U <备份账号> \
-Fc -j 8 -Z 5 \
--no-owner --no-privileges \
-f /data/dump/backup.dump \
<数据库名>
-j 8表示用 8 个并行线程导出，能明显提升大表较多的场景下的导出速度。-Z 5是压缩级别，1 到 9 之间，5 是速度和体积的平衡点。--no-owner --no-privileges说明一点：权限和 owner 信息我打算单独处理，不混在数据备份里。这样恢复时可以减少无关报错，而且目标端的角色名不一定和源端完全一致，先不限制 owner 更灵活。
导出过程中要格外注意对源库的压力。如果是生产库，建议先看监控，避免在业务高峰时段执行。pg_dump 的并行导出会同时发起多个查询，对 CPU 和 IO 都有一定消耗。如果源库本身就比较紧张，可以把并行度降到 4，或者使用 --table 参数分批导出大表。
还有一个细节我吃过亏：如果数据库里有大对象（Large Objects），比如通过 lo 类型存了一些文档、图片，那么 pg_dump -Fc 默认是包含大对象的，但你如果只导出了部分 schema，大对象可能不会跟着导出。这次迁移前我特意查了一下源库是否有大对象：
sql复制SELECT count(*) FROM pg_largeobject_metadata;
如果有，就要确认导出命令里确实包含了它们，并且在恢复后验证数量一致。
3.2 传输阶段：断点续传、加密与完整性校验
导出文件生成之后，传输就成了下一个瓶颈。跨云环境下，你通常不能直接把文件推到目标数据库服务器上，而是需要先传到本地的中转机、再从云端跳板机拉进去。我这次采用了“本地中转 + 双段传输”的策略。
第一步，从源库所在云平台把备份文件下载到本地中转机，或者通过云厂商的对象存储服务中转。下载时我用的是带断点续传的工具，比如 rsync --partial --progress。为什么不用 scp？因为 scp 不支持断点续传，一旦网络中断就得重新开始。几百 GB 的文件，重新传一次的时间成本太高。
第二步，把文件从中转机传到目标云环境。目标端如果是云服务器（ECS/CVM 之类的），可以用 scp 或 rsync；如果是托管数据库实例，通常需要先传到同 VPC 内的跳板机，再通过内网访问目标库。
传输完成之后，绝不能直接开始导入，先做校验：
bash复制# 在源端生成校验值
sha256sum backup.dump > backup.dump.sha256
# 在目标端核对
sha256sum -c backup.dump.sha256
这一步看似多余，但能避免很多低级问题。跨公网传大文件，偶尔会遇到文件损坏、字节数不对的情况，不校验就导入，恢复了半天才发现某些数据段是坏的，到时候定位问题会非常痛苦。
传输期间还可以做一件事：我先用 pg_dumpall --globals-only 导出了角色和全局对象，提前在目标端执行。这样角色、表空间这类对象先建好，后面 pg_restore 导入时就不会因为缺角色而报错。
3.3 导入阶段：顺序、并行度与参数取舍
导入是整个迁移链路里最耗时、也最容易出问题的一步。pg_restore 的恢复顺序默认是先恢复结构（pre-data）、再恢复数据（data）、最后恢复索引和约束（post-data）。这个顺序是官方推荐的，也是经过大量实践验证的——先建表结构，再灌数据，最后一次性建索引，比边导入边建索引要快得多，因为避免了反复维护索引的开销。
我这次的导入命令：
bash复制pg_restore -h <目标库地址> -p 5432 -U <恢复账号> \
-d <目标数据库> \
-Fc -j 8 \
--no-owner --no-privileges \
--disable-triggers \
/data/dump/backup.dump
几个关键的取舍：
-j 8：并行度。不是越高越好。并行恢复会同时开多个数据库会话，受限于目标库的 CPU、磁盘 IO 和锁冲突。我观察到的规律是：表数量多、单表数据量不大时，并行效果明显；如果只有几张几十 GB 的大表，并行帮助有限，甚至会因为 IO 争抢变慢。建议从 4 或 8 开始试，根据导入速度动态调整。--disable-triggers：恢复数据时禁用触发器，等数据全部导入后再一次性启用。这个选项需要恢复账号具有 superuser 权限，如果目标云实例不给你真超级用户，这个参数可能用不了，需要提前和云厂商确认。--no-owner --no-privileges：我导出时不带 owner 和权限，恢复时也不恢复 owner，这意味着所有对象统一归恢复账号所有。所以我在导入前会用pg_dumpall --globals-only先把角色建好，再考虑后续用ALTER TABLE ... OWNER TO或者GRANT把权限修正到位。
导入前，我还会在目标实例上临时调整几个参数来加速导入。以 PostgreSQL 15 为例：
sql复制-- 适合导入期间临时调整的参数
ALTER SYSTEM SET max_wal_size = '16GB';
ALTER SYSTEM SET maintenance_work_mem = '2GB';
ALTER SYSTEM SET synchronous_commit = 'off';
ALTER SYSTEM SET fsync = 'off';
SELECT pg_reload_conf();
fsync = off 这个参数争议比较大，它意味着 PostgreSQL 不再等待数据落盘，一旦操作系统崩溃或断电，数据可能损坏。但如果你只是在导入阶段临时开启、导入完成后立刻恢复为 on，并且目标实例有高可用保障，那风险是可控的。实际使用中我确实通过这个配置把导入时间缩短了将近三分之一。但要注意：synchronous_commit = off 只影响事务提交确认，不影响数据最终写入；fsync = off 才是真正激进的那个，务必只在可接受风险的前提下使用，并且导入完成后第一时间改回来。
导入完成后，我会先检查日志有没有 ERROR。pg_restore 默认不会因为某个对象恢复失败就中断整个任务，它会把错误记到日志里继续跑。所以导入结束不代表成功，必须回头翻日志。这是我踩过最深的坑之一：当时导入命令执行完，退出码还是 0，但日志里其实混了好几条 ERROR: relation "xxx" does not exist，导致后面数据校验阶段才发现问题。
4. 排查实录：迁移过程中踩过的典型报错
4.1 扩展插件对不上的第一道坎：pgcrypto、uuid-ossp 与 pgvector
跨云迁移最容易在扩展这一步翻车。当时我导入到某个业务库时，报错信息非常直接：
code复制ERROR: extension "pgcrypto" is not available
DETAIL: Could not open extension control file "/usr/share/pgsql/extension/pgcrypto.control": No such file or directory.
HINT: Please install the extensions with the contrib package.
排查链路不复杂。我先在源库查了一下有哪些扩展：
sql复制SELECT extname, extversion FROM pg_extension;
结果里有 pgcrypto、uuid-ossp、pgvector。再回到目标云的控制台查一下可用扩展列表，发现 pgcrypto 和 uuid-ossp 没有默认开放。原因很现实：云厂商为了实例安全，默认不会把所有 contrib 模块都装上，尤其是需要额外安装或者涉及安全敏感功能的扩展。
解决方案分两种路径。如果目标实例是自建的 PostgreSQL，直接安装对应的 contrib 包就能解决：
bash复制# CentOS / RHEL 系
yum install postgresql15-contrib pgvector_15
如果目标实例是云托管数据库，那就得走工单或者控制台开启扩展。我还遇到过一种情况：目标云平台提供了 pgvector，但版本比源库旧，导入时 CREATE EXTENSION vector 报错版本不匹配。这时候要么找云厂商升级，要么在导入时先跳过这个 schema，再用目标版本重新创建扩展、重灌该扩展相关的数据。
pgvector 这个扩展现在用得越来越多，而且有个比较特殊的问题：它在不同平台上常常以不同方式分发，比如 Windows 上需要手动下载对应的 DLL 文件，Linux 上需要匹配 PostgreSQL 版本号编译安装。如果你在迁移测试环境里用了 Docker 部署 PostgreSQL，建议直接用官方镜像的 pgvector/pgvector:pg15 这类带扩展的镜像，省去编译的麻烦。
4.2 字符集与排序规则不一致引发的隐性故障
另一类隐蔽问题出在字符集和排序规则上。源库是 A 云创建的，建库时默认用了 zh_CN.UTF-8 的 LC_COLLATE 和 LC_CTYPE；目标实例在 B 云初始化时，用的可能是 C 或者 en_US.UTF-8。这种不一致在数据导入阶段不一定报错，但会在某些特定 SQL 上暴露问题。
比如一条依赖排序规则的查询：
sql复制SELECT * FROM users ORDER BY username COLLATE "zh_CN.UTF-8";
在目标库执行时直接报错：
code复制ERROR: collation "zh_CN.UTF-8" for encoding "UTF8" does not exist
更隐蔽的是，即使不显式指定 COLLATE，如果源库某些列或者索引依赖了特定 collation，而目标库默认 collation 不同，那么索引的排序顺序可能和之前不一样，进而影响查询计划，甚至让某些应用逻辑得到不同的排序结果。
我的排查方法是：在导入数据之前，先对比源库和目标库的数据库属性。
sql复制SELECT datname, pg_encoding_to_char(encoding), datcollate, datctype
FROM pg_database;
如果发现不一致，最好的选择是在目标端重新初始化实例，并在初始化时指定和源库一致的 --locale。如果目标库已经建好且无法重新初始化，可以尝试新建一个数据库并显式指定 LC_COLLATE 和 LC_CTYPE，然后导入到新库：
sql复制CREATE DATABASE target_db
WITH ENCODING 'UTF8'
LC_COLLATE 'zh_CN.UTF-8'
LC_CTYPE 'zh_CN.UTF-8'
TEMPLATE template0;
但这里有个前提：目标云平台的操作系统里必须安装了对应的 locale。如果没安装，需要让云厂商或者运维侧先把 locale 装好。这个事看起来小，但一旦在切流前一天才发现，就非常被动。
4.3 导入慢到怀疑人生：数据层和应用层的原因共同排查
这次迁移中，导入阶段有个库跑了近三个小时还没完成，我当时的第一反应是并行度不够。我把 -j 从 4 提到 8，快了一点，但依然远低于预期。后来才发现，问题根本不在 pg_restore 的并行度，而是源库里有几张表存在严重的 TOAST 膨胀。
TOAST 是 PostgreSQL 处理大字段的机制，当一行数据超过约 2KB 时，超出的部分会被压缩并移到 TOAST 表里。如果表里有大量 text/jsonb 字段，并且以前经历过频繁的更新，TOAST 表可能膨胀得非常厉害。逻辑导出时会把这些数据全部读出来再压缩写入，代价极高。
排查办法很直接：查一下大表的物理大小和 TOAST 大小。
sql复制SELECT relname,
pg_size_pretty(pg_total_relation_size(relid)) AS total_size,
pg_size_pretty(pg_relation_size(relid)) AS heap_size,
pg_size_pretty(pg_total_relation_size(relid) - pg_relation_size(relid)) AS toast_index_size
FROM pg_stat_user_tables
WHERE relname IN ('big_table_a', 'big_table_b')
ORDER BY pg_total_relation_size(relid) DESC;
这时候会看到某些表的 TOAST + 索引大小比主表还大好几倍。遇到这种情况，有个比较实用的经验：先 VACUUM FULL 源库中 TOAST 膨胀严重的表，再重新导出，能让导出文件体积明显下降，导入速度也随之提升。注意 VACUUM FULL 会锁定表，需要安排在业务低峰或维护窗口。
另外，导入慢也可能是目标库的磁盘性能问题。我后来查了目标云实例的监控，发现磁盘 IOPS 已经打到上限。解决办法是用更高 IOPS 的磁盘类型重新创建实例，或者把并行度降下来，避免 IO 争抢导致整体吞吐量下降。这个事让我学到一个教训：迁移前要先做一次小规模数据导入的“压测”，用 1GB 左右的数据试导入，观察耗时和资源消耗，再决定最终的并行度。
4.4 角色、权限与序列：最容易在收尾阶段翻车的三件事
角色和权限的问题，往往发生在数据导入完成之后、应用连接测试的时候。我当时恢复完数据后，应用连上来报了一堆 permission denied for table xxx。原因是恢复时我装了 --no-owner --no-privileges，所有表的 owner 都是恢复账号，而应用账号没有权限。
解决办法不是一个个手动 GRANT，而是提前准备好权限脚本。我的做法是：在源库查询所有业务角色和默认权限，在目标端重新创建角色和密码，然后统一授权。
sql复制-- 源库查看默认权限
SELECT pg_get_userbyid(d.defacluid) AS owner,
n.nspname AS schema,
d.defaclobjtype,
d.defaclacl
FROM pg_default_acl d
LEFT JOIN pg_namespace n ON n.oid = d.defaclnamespace;
然后在目标端把这些 default ACL 还原回去。这个步骤容易漏，因为角色权限不一定都在表上，可能是 schema 级别或者默认权限。不还原的话，后续应用新建表时又会遇到权限缺失。
序列的坑更多。逻辑备份恢复后，PostgreSQL 的序列值不会自动同步到当前数据的最大值。比如某张表的 id 序列，源库已经走到 100000，恢复后序列值可能还是 1，应用一插入新数据就会报主键冲突。修复方法很机械，但要遍历所有表：
sql复制-- 对每个表执行一次
SELECT setval('users_id_seq', COALESCE((SELECT max(id) FROM users), 1));
如果要一次搞定，可以用 PL/pgSQL 自动遍历所有序列。我习惯在导入完成后立刻跑一个“序列修复脚本”，避免应用联调时才发现问题。
5. 生产就绪的最后一步：验证、切流与回滚
5.1 数据一致性验证：行数只是地基，不是全部
做全量迁移，最怕的是数据“看着对、实际不对”。我的验证策略分三层。
第一层是全表行数核对。用脚本连接源库和目标库，对每张表执行 SELECT count(*) FROM table，对比行数是否一致。这个方案简单直观，但对大表来说 count(*) 本身就很慢。我的变通做法是：对超大表用抽样统计，比如按时间字段分区统计最近几个时间段的总数，或者用 pg_stat_user_tables.n_live_tup 做近似对比，再对关键表做精确 count。
第二层是抽样校验具体数据。选几张大表，抽查一部分行的关键业务字段，用 md5 聚合对比：
sql复制-- 源库
SELECT md5(string_agg(md5(t::text), ''))
FROM (SELECT col1, col2, col3 FROM big_table ORDER BY id LIMIT 1000) t;
-- 目标库执行同样的查询，对比结果
这个办法比逐行对比快得多，而且能发现具体的数值差异。要注意的是查询结果必须稳定排序，否则 md5 会不一致。
第三层是业务逻辑校验。我会让应用团队在只读模式下跑一遍核心接口，比如订单查询、用户登录、报表统计，确保关键路径没有报错。这一层能覆盖数据层检测不到的语义问题，比如某些触发器、函数、视图的返回结果和旧库不一致。
5.2 应用连接切换的技术细节
数据验证通过后，接下来就是切流。切流的技术细节很重要，但不能只从“改个连接串”来考虑。
我会先让应用团队准备一份配置回退方案：把连接地址、端口、用户名、密码全部记下来，写成可复原的脚本。切换顺序是：先切换只读应用，观察日志和监控；确认稳定后，再切换读写应用。
如果应用使用了连接池（比如 PgBouncer、HikariCP），要注意连接池里可能还存着旧库的连接。切换 DNS 或者连接配置后，旧的连接不会立刻断开，这会导致一部分写入还是到了源库。稳妥的做法是：切换前主动清空连接池，或者在维护窗口内重启应用节点。
还有一个细节：如果目标库的 max_connections 比源库小，而应用连接池配置没变，切流后可能直接出现连接超限。我这次就遇到目标实例默认只有 200 个连接，而源库是 500，应用连接池一启动就报错。后来在导入前提前调整了目标实例的连接数配置，才避免了这个问题。
5.3 回滚与止损：提前练过，才敢切
全量迁移最怕的是切流后发现问题，却没有回滚预案。我的原则是：任何切流动作，都必须在切换前把回滚条件写清楚。
回滚方案的第一步是保证源库仍然可用，并且切换期间源库保持只读状态。如果业务切过去之后发现目标库有严重问题，最多只丢失切流后写入目标库的数据，源库的数据还在原地。操作上我会在停机开始前，先把源库改成只读事务模式，记录切换时间点；回滚时，只需要把应用连接指回源库，再恢复读写。
为了验证回滚方案有效，我会在测试环境完整演练一次：先切到目标库，再故意制造一个“严重问题”，然后执行回滚。很多团队觉得这是浪费时间，但真正出问题的时候，有演练过的回滚流程和没有演练过，完全是两回事。
回滚的判断条件也需要提前定义。我通常会约定：切流后的 30 分钟内，如果出现以下情况之一，立即回滚——应用错误率超过 5%、关键接口响应时间超过旧库的 3 倍、数据校验发现主表关键字段大面积不一致。如果超过 30 分钟仍然稳定，就认为目标库已经接过生产流量，回滚窗口关闭，开始收尾。
我个人的体会是，跨云跨版本全量迁移，七分靠准备，三分靠执行。导出、传输、导入这些命令其实都很简单，难的是提前识别那些隐藏在版本差异、云平台特性、权限模型和数据特征里的“暗坑”。把每一层都验证到位，生产切换就没有想象中那么可怕。
最后再分享一个操作习惯：迁移结束后，我会把这次用过的所有命令、报错、日志、调整过的参数整理成一个文档，放到团队的知识库里。下次再遇到类似迁移，直接拿这个文档改改就能用，比重新踩一遍坑要省力得多。