PostgreSQL迁移到国产数据库怎么做？评估、改造、上线全流程实操指南

📌今日关键词：PostgreSQL迁移、国产数据库、PL/pgSQL、数据迁移、信创替代

---

大家好，我是数据库小学妹 👋

最近有个朋友吐槽：公司核心系统跑了好几年PostgreSQL，结果信创审计来了，领导一句"年内替换"，整个DBA团队头都大了。

他在群里向大家求助："PG迁到国产库，到底要改多少东西？"

群里炸锅了。有人说存储过程改到怀疑人生，有人说JSONB字段迁移踩了一堆坑，还有人说数组类型直接放弃改成关联表。

我也好奇：PG上那些我们习以为常的语法，换个库到底还能不能跑？今天就来梳理一下：评估怎么做、对象怎么改、数据怎么搬、上线怎么切。

---

一、PostgreSQL迁移，先搞清楚要搬哪些东西

PostgreSQL上跑了几年的系统，数据库里的东西比你想的多。迁移前先盘点。

1.1 对象清单

你需要摸清这些东西：

• 表和索引： 数量、总数据量、最大单表行数
• 存储过程和函数： 数量、总代码行数、有没有用PL/pgSQL特有语法
• 视图： 有没有用到PostgreSQL特有的系统视图或information_schema扩展
• 触发器： 数量和复杂度，有没有用PL/pgSQL写的触发器函数
• 序列和标识列： ID生成方式，有没有用serial/bigserial
• JSONB字段： 用了多少、查询时有没有用@>?、?|等操作符
• 数组类型： integer\[\]、text\[\]这些用在哪几张表
• 权限和角色： PostgreSQL的权限模型和目标库的映射关系

看到这么多是不是头都大了？别慌，其实拿个迁移评估工具（比如KDMS）扫一遍PG源库，就能自动生成对象清单和兼容性报告。比手动盘点快，也不容易漏。当然，手搓Excel也不是不行，就是累点。

1.2 兼容性评估

PostgreSQL有几个用得特别多的特性，迁移时容易踩坑：

PG特性	迁移情况	优先级
PL/pgSQL存储过程	语法需改造为PL/SQL	高
JSONB类型和操作符	KES原生兼容@>、?等操作符	低
数组类型	KES支持VARRAY映射	低
CTE递归查询	WITH RECURSIVE语法差异	中
窗口函数扩展	部分PG特有窗口函数不通用	中
外部数据包装器(FDW)	配置方式完全不同	中
COPY命令	大数据量导入导出方式差异	低
扩展插件(PostGIS等)	需要目标库有对应空间扩展	低

二、PL/pgSQL存储过程改造，最费人力的环节

PL/pgSQL是PG的存储过程语言。系统里存储过程多的话，这部分改造是工作量的重头。

2.1 函数和存储过程改写

先看函数迁移。以下是PG函数迁移为KES函数的示例：

-- PostgreSQL PL/pgSQL函数
CREATE OR REPLACE FUNCTION get_order_total(p_order_id INT)
RETURNS DECIMAL(12,2) AS $$
DECLARE
  v_total DECIMAL(12,2);
  v_status VARCHAR(20) := 'active';
BEGIN
  SELECT SUM(amount) INTO v_total
  FROM order_items
  WHERE order_id = p_order_id AND status = v_status;
  RETURN v_total;
END;
$$ LANGUAGE plpgsql;

-- KES函数（Oracle兼容模式）
CREATE OR REPLACE FUNCTION get_order_total(
  p_order_id IN NUMBER)
RETURN NUMBER AS
  v_total NUMBER(12,2);
  v_status VARCHAR2(20) := 'active';
BEGIN
  SELECT SUM(amount) INTO v_total
  FROM order_items
  WHERE order_id = p_order_id AND status = v_status;
  RETURN v_total;
END;

再看存储过程，语法有所不同：

-- PostgreSQL PL/pgSQL存储过程
CREATE OR REPLACE PROCEDURE update_order_status(
  p_order_id INT, p_new_status VARCHAR)
LANGUAGE plpgsql AS $$
BEGIN
  UPDATE orders SET status = p_new_status
  WHERE id = p_order_id;
  COMMIT;
END;
$$;

-- KES存储过程（Oracle兼容模式）
CREATE OR REPLACE PROCEDURE update_order_status(
  p_order_id IN NUMBER, p_new_status IN VARCHAR2)
AS
BEGIN
  UPDATE orders SET status = p_new_status
  WHERE id = p_order_id;
  COMMIT;
END;

主要差异：

• PG用$$ ... $$ LANGUAGE plpgsql包裹，KES不需要
• PG函数的RETURNS在KES中是RETURN
• PG用DECIMAL，KES用NUMBER
• PG存储过程的LANGUAGE plpgsql声明在KES中统一去掉
• PG的VARCHAR在KES中改为VARCHAR2

2.2 JSONB操作

PostgreSQL的JSONB是迁移中的高频话题。很多人以为JSONB迁到国产库要拆字段，其实不用。

KES原生支持JSONB类型，包括@>、?、->>等操作符。PG的JSONB字段可以直接迁，不改也能跑。

-- PostgreSQL JSONB查询（KES中原封不动可用）
SELECT data->>'name' AS name,
       data->'address'->>'city' AS city
FROM customers
WHERE data @> '{"status": "active"}';

-- 仅当原生兼容测试不过时，才考虑拆字段方案
ALTER TABLE customers ADD COLUMN name VARCHAR(100);
ALTER TABLE customers ADD COLUMN city VARCHAR(100);
-- 将JSONB数据拆到独立列

简单说：先拿KDMS扫一遍，确认JSONB操作符兼容性。绝大多数场景下直接迁移就行，拆字段是最后的兜底方案。

2.3 数组类型

PostgreSQL的数组类型，同样可以不走拆表这条路。

KES在Oracle兼容模式下支持VARRAY（可变数组）类型，PG的数组字段映射为VARRAY就行，结构改动很小。

-- PostgreSQL数组
CREATE TABLE products (
  id SERIAL PRIMARY KEY,
  name TEXT,
  tags TEXT[]
);
SELECT * FROM products WHERE 'electronics' = ANY(tags);

-- KES改造方案
-- 方案一：VARRAY映射（推荐）
-- PG的TEXT[]可直接映射为KES的VARRAY类型，查询语法微调
SELECT * FROM products
WHERE 'electronics' MEMBER OF tags;

-- 方案二：拆为关联表（查询逻辑复杂时备用）
CREATE TABLE product_tags (
  product_id INT,
  tag VARCHAR(100)
);

大部分场景下，VARRAY映射就够了。拆关联表只在数组嵌套深、查询逻辑绕的时候才需要。

---

三、数据迁移执行方案

对象改完之后，数据怎么搬？

3.1 全量迁移

通过迁移工具（如KDTS），可以将PostgreSQL的数据库结构和数据搬迁到KES：

1. 结构迁移： 自动转换表结构、索引、约束、序列等DDL
2. 数据导出： 从PG导出数据，支持并行导出提升速度
3. 数据导入： 批量导入到KES，支持事务控制和断点续传
4. 对象迁移： 存储过程、视图、触发器的DDL转换

小体量数据（几十GB以内）可以用pg_dump导出SQL脚本，在KES中执行。大体量数据用KDTS，并行迁移效率高得多。

3.2 增量同步和双轨并行

核心系统没法停机迁移，得上双轨并行：

• 增量同步（Kingbase FlySync）： 基于日志捕获PG数据变更，实时同步到KES。两个库同时跑，业务无感知。
• 数据校验（KDC)： 自动比对源库和目标库的一致性。逐表对比，找出差异。

3.3 灰度切换

上线别一步到位，分阶段来：

1. 读写分离阶段： 读请求切到KES，写请求还在PG
2. 灰度切流： 按业务模块逐步切换到KES
3. 全量切换： 所有请求切到KES
4. 观察期： 保留PG作为回滚方案，确认稳定后再下线

---

四、真实迁移案例

以某大型制造企业ERP系统迁移为例，与白象集团、一汽奔腾等制造企业的迁移路径类似。

迁移规模：

• 表：600多张
• 存储过程和函数：数千个
• JSONB字段：数十个表中使用

迁移过程：

1. KDMS评估，扫描出兼容性问题数千个，90%以上可自动修复
2. 人工改造：剩余部分主要是PL/pgSQL特有语法、少量数组类型映射
3. 双轨并行：运行6周，期间KDC持续校验数据一致性
4. 全量切换：通过灰度策略平滑上线

迁移效果：

• 运维成本降低40%（从老旧服务器迁移到新硬件平台）
• 核心查询性能持平，部分场景提升1.5倍
• 信创审计一次通过

---

小结

PostgreSQL迁移最关键的环节：PL/pgSQL到PL/SQL的语法改造（函数和存储过程差异大，最费人力），JSONB和数组类型（KES原生兼容，多数情况直接迁就行）。增量同步阶段的数据一致性是生产系统绕不开的硬要求。

工具能搞定大部分自动化迁移。存储过程改造还是需要有经验的DBA上。先用KDMS做评估，量化问题------上面的制造企业案例里，数千个兼容性问题，90%以上工具自动修了，剩下的人工改几周就能搞定。

大家的系统有PostgreSQL要迁吗？遇到最头疼的问题是什么？评论区聊聊 👇

---

我是数据库小学妹，咱们下篇见 👋