告别兼容焦虑：电科金仓 KES 如何把 Oracle 的 PL/SQL 和 JSON 业务"接住"
真正做过 Oracle 迁移的人都知道，最怕的不是数据量大，而是业务逻辑压在数据库里动不了。在多个项目里实践下来，电科金仓 KingbaseES（KES）在 PL/SQL 兼容和 JSON 处理这两点上，确实帮我省下了不少时间。
一、写在前面：迁移时，最先被问到的三个问题
在信创项目里，只要提到"Oracle 替换"，几乎都会被连续追问三件事：
- 现有存储过程要不要全部重写？
- 那些年堆出来的 PL/SQL 能不能跑？
- 现在大量用 JSON 的地方，性能会不会崩？
这些问题如果答不好，迁移方案基本就很难往下走。
从实际项目经验来看，电科金仓 KES 给到的答案是：能跑、少改、风险可控。下面我就围绕 PL/SQL 和 JSON 这两块，结合实际使用情况，展开说说它到底解决了什么问题。
二、PL/SQL：决定迁移成本的"分水岭"
2.1 为什么 PL/SQL 才是真正的难点
很多系统嘴上说是"Java 应用"，但真正复杂的规则，其实都在数据库里：
- 核心结算逻辑写在存储过程中
- 校验、补偿、统计放在触发器里
- 各种历史遗留包，没人敢动
如果迁移数据库意味着推倒重来，那项目大概率会直接流产。
KES 在这一点上的策略很明确：尽量按 Oracle 的方式来，而不是强迫业务迁就新数据库。
2.2 实际体验：多数存储过程可以直接过
下面这个过程，来自我在项目里常见的一类写法，逻辑不复杂，但细节很多：
sql
CREATE OR REPLACE PROCEDURE calculate_bonus (
p_emp_id IN NUMBER,
p_bonus OUT NUMBER
) AS
v_salary NUMBER;
v_performance_rating NUMBER;
BEGIN
v_performance_rating := 0;
SELECT salary INTO v_salary
FROM employees
WHERE emp_id = p_emp_id;
IF v_salary > 10000 THEN
SELECT performance_score * 0.15 INTO v_performance_rating
FROM performance_reviews
WHERE emp_id = p_emp_id
AND review_year = EXTRACT(YEAR FROM SYSDATE) - 1;
ELSE
SELECT performance_score * 0.10 INTO v_performance_rating
FROM performance_reviews
WHERE emp_id = p_emp_id
AND review_year = EXTRACT(YEAR FROM SYSDATE) - 1;
END IF;
p_bonus := v_salary * GREATEST(v_performance_rating, 0.05);
EXCEPTION
WHEN NO_DATA_FOUND THEN
p_bonus := v_salary * 0.05;
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, '计算奖金时发生错误: ' || SQLERRM);
END;在 KES 环境下，这类代码几乎不需要调整 。
变量声明、异常处理、内置函数、控制结构，基本都能对齐 Oracle 行为。
👉 这点非常关键 ：
迁移不是"语法能不能写"，而是"历史代码能不能活"。
2.3 游标、%TYPE、%ROWTYPE 这些老朋友还在
很多老系统严重依赖游标，尤其是按行处理逻辑。KES 对这块支持得比较完整：
sql
DECLARE
CURSOR emp_cursor IS
SELECT emp_id, emp_name, salary, department_id
FROM employees
WHERE hire_date > DATE '2020-01-01'
ORDER BY salary DESC;
v_emp_record emp_cursor%ROWTYPE;
v_department_name departments.department_name%TYPE;
BEGIN
OPEN emp_cursor;
LOOP
FETCH emp_cursor INTO v_emp_record;
EXIT WHEN emp_cursor%NOTFOUND;
SELECT department_name INTO v_department_name
FROM departments
WHERE department_id = v_emp_record.department_id;
DBMS_OUTPUT.PUT_LINE(
'员工: ' || v_emp_record.emp_name ||
', 部门: ' || v_department_name ||
', 薪资: ' || v_emp_record.salary
);
END LOOP;
CLOSE emp_cursor;
END;这一类写法如果不能兼容，迁移基本没法推进。
好在 KES 在这里并没有"另起炉灶"。
2.4 内置包不是摆设，是真的能用
DBMS_OUTPUT、DBMS_SQL、DBMS_LOB 这些包，在调试和历史逻辑里非常常见。
sql
BEGIN
DBMS_OUTPUT.ENABLE(1000000);
FOR i IN 1..5 LOOP
DBMS_OUTPUT.PUT_LINE('循环次数: ' || i);
DBMS_OUTPUT.PUT_LINE(
'当前时间: ' ||
TO_CHAR(DBMS_UTILITY.GET_TIME, 'YYYY-MM-DD HH24:MI:SS')
);
END LOOP;
END;从可用性角度讲，不是"名字一样"就行，而是行为要接近，这一点 KES 做得相对稳。
三、函数与分析能力：不是"能跑"，而是"够用"
3.1 日常函数支持情况
字符串、日期、数值这些基础函数，不展开吹，直接看用起来顺不顺：
sql
SELECT
LOWER('Hello World'),
ADD_MONTHS(SYSDATE, 3),
MONTHS_BETWEEN(SYSDATE, DATE '2023-01-01')
FROM dual;这类语句在迁移中属于"最不想碰的"，KES 基本不会给你添堵。
3.2 分析函数：迁移后最容易被低估的能力
不少系统其实非常依赖窗口函数，比如排名、同比、滚动统计。
sql
SELECT
emp_id,
department_id,
salary,
RANK() OVER (PARTITION BY department_id ORDER BY salary DESC),
ROW_NUMBER() OVER (PARTITION BY department_id ORDER BY salary DESC)
FROM employees;KES 对这类语法支持完整，这一点对报表系统、统计系统尤为重要。
四、JSON：不是"支持"，而是"能不能放心用"
4.1 JSON 和 JSONB，别选错
KES 提供 JSON / JSONB 两种类型，本质和 PostgreSQL 类似：
- JSON：保留原始文本
- JSONB：二进制存储，查询更快
如果是业务字段频繁查询，我个人建议直接 JSONB，不要犹豫。
4.2 常见 JSON 场景实战
建表、写入、查询这几个动作，决定了你能不能在生产环境用得住。
sql
CREATE TABLE products (
id SERIAL PRIMARY KEY,
product_info JSONB,
created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
);
sql
SELECT
product_info->>'name',
product_info->'specs'->>'brand'
FROM products
WHERE (product_info->>'in_stock')::boolean = true;语法不花哨，但胜在稳定、清晰、可维护。
4.3 JSON 更新和索引，性能差距就在这
如果 JSON 查询慢，九成问题出在索引上：
sql
CREATE INDEX idx_products_info
ON products USING GIN (product_info);
CREATE INDEX idx_products_brand
ON products ((product_info->'specs'->>'brand'));这一步不做，JSON 用得越多，锅背得越狠。
五、迁移中绕不开的几个现实问题
5.1 CONNECT BY 怎么办？
老方案不用扔，递归 CTE 就能解决：
sql
WITH RECURSIVE org_hierarchy AS (
SELECT 1 AS level, employee_id, manager_id
FROM employees
WHERE manager_id IS NULL
UNION ALL
SELECT oh.level + 1, e.employee_id, e.manager_id
FROM employees e
JOIN org_hierarchy oh ON e.manager_id = oh.employee_id
)
SELECT * FROM org_hierarchy;5.2 MERGE 语句？
这一点反而轻松，KES 是直接支持的，不用改写。
六、一些个人判断（不是宣传话术）
从实际迁移经验看，我对电科金仓 KES 的评价很简单：
- PL/SQL 是真的想帮你接住历史包袱
- JSON 能用，而且用得住
- 迁移风险可控，不靠赌运气
数据库迁移从来不是技术炫技，而是能不能让系统平稳落地。
在当前信创背景下，KES 至少在"Oracle 平替"这条路上，走得比较务实。
七、结语
如果你正在评估国产数据库替代 Oracle，我的建议是：
不要只看 PPT，一定要跑一轮真实业务代码。
从 PL/SQL 到 JSON，从老逻辑到新需求，KES 给出的不是完美答案，但确实是一个现实可落地的选择。
迁移这件事，本就不该追求"零成本"，而是追求可控、可回退、可持续 。
在这一点上，电科金仓 KES，至少没有让人失望。