📌今日关键词：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函数的示例：

```sql
-- 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;
```

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

```sql
-- 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字段可以直接迁，不改也能跑。

```sql
-- 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就行，结构改动很小。

```sql
-- 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要迁吗？遇到最头疼的问题是什么？评论区聊聊 👇

---

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


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

PostgreSQL到国产数据库迁移实战：存储过程兼容性与增量同步方案

自建PostgreSQL数据库迁移到国产数据库的全流程实操：兼容性评估、PL/pgSQL改造、数据同步、灰度切换，覆盖存储过程、JSONB、数组等核心对象处理方案。

后端

数据库

运维

PostgreSQL迁移国产数据库实战指南：PL/pgSQL存储过程改造、JSONB字段处理、数组类型映射方案详解。提供全量迁移与增量同步策略，分享制造企业ERP系统成功案例，降低40%运维成本。涵盖信创替代关键技术与工具推荐，助力企业平滑完成数据库国产化转型。

数据一致性

数据迁移

PostgreSQL

大数据

服务器

2026年中大促 | AI 领航 智绘未来

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

PostgreSQL到国产数据库迁移实战：存储过程兼容性与增量同步方案-腾讯云开发者社区-腾讯云

PostgreSQL到国产数据库迁移实战：存储过程兼容性与增量同步方案

PostgreSQL到国产数据库迁移实战：存储过程兼容性与增量同步方案

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐