前言
在数据库国产化替代里，DBA 和开发最头疼的从来不是普通数据迁移，而是埋在业务里多年的"黑魔法"------Oracle 专属的层次查询 和伪列 。
这些语法支撑着无数系统的组织架构、菜单权限、BOM 清单、事务逻辑，一旦新库不兼容，就意味着成百上千行 SQL 要重写、业务逻辑要重构，风险和成本直接拉满。
- 现在可以很实在地说一句：这部分迁移焦虑，真的可以结束了。
- 金仓 ES（KingbaseES）V9 已经在内核层面，实现了对 Oracle 这些高级特性的无感兼容。
下面我们就用通俗讲解、代码对比、流程图解，带你看清：金仓 ES 是怎么稳稳接住 Oracle 这些"高难度动作"的。
一、先讲痛点：为什么层次查询和伪列是迁移拦路虎？
在 Oracle 里，处理树形结构（部门层级、菜单权限、分类树）几乎离不开这两套东西：
START WITH ... CONNECT BY层次查询语法ROWNUM、ROWID、LEVEL等伪列
传统国产化迁移，经常卡在这几点：
- 语法不兼容
很多库只支持标准递归 CTE，所有CONNECT BY必须重写成WITH RECURSIVE，逻辑绕、易出错、工作量巨大。 - 伪列直接缺失
ROWID、LEVEL这类 Oracle 特色"伪列"在标准 SQL 里不存在，没做兼容的数据库一跑就报错。 - 性能掉得厉害
就算在应用层硬模拟出来，也丢了数据库内核优化，查询性能直接断崖式下跌。
金仓 ES 的解决思路很直接：
不只支持标准 SQL，更原生兼容 Oracle 层次查询语法 + 全套常用伪列。
大部分涉及树形结构、伪列的 SQL，不用改一行代码，直接在金仓 ES 上正常跑。
二、深度讲透：层次查询，金仓 ES 做到原汁原味兼容
2.1 语法层面：Oracle 怎么写，金仓 ES 就怎么认
Oracle 里最经典的树形查询大家肯定熟：
sql
-- Oracle 写法：查员工上下级关系
SELECT employee_id, last_name, manager_id, LEVEL
FROM employees
START WITH employee_id = 100
CONNECT BY PRIOR employee_id = manager_id;金仓 ES 在内核层完整解析这套语法，不是简单翻译，是原生支持，包括：
- 基础父子层级遍历
NOCYCLE防止环路死循环CONNECT_BY_ROOT取根节点CONNECT_BY_ISLEAF判断是否叶子节点SYS_CONNECT_BY_PATH拼接层级路径- 甚至
ORDER SIBLINGS BY同层级排序
不管是 PRIOR col = col 还是 col = PRIOR col，都能正确识别，不用微调语法。
2.2 实战对比：一换库就懂差距有多大
场景：查询部门树，带层级、完整路径、是否叶子节点。
传统迁移：必须重写递归 CTE，又长又难维护
如果数据库不兼容 Oracle 语法，你只能这么写：
sql
-- 非兼容库：必须改成递归 CTE
WITH RECURSIVE dept_tree AS (
SELECT dept_id, dept_name, parent_id,
1 AS lvl,
CAST(dept_name AS VARCHAR(1000)) AS path
FROM departments
WHERE parent_id IS NULL
UNION ALL
SELECT d.dept_id, d.dept_name, d.parent_id,
t.lvl + 1,
t.path || ' -> ' || d.dept_name
FROM departments d
JOIN dept_tree t ON d.parent_id = t.dept_id
)
SELECT * FROM dept_tree;逻辑复杂、改动量大、老代码维护成本飙升。
金仓 ES 迁移：Oracle 代码直接复制粘贴跑
sql
-- 金仓 ES：直接运行 Oracle 原版 SQL
SELECT
dept_id,
dept_name,
parent_id,
LEVEL AS current_level, -- 伪列 LEVEL 直接用
SYS_CONNECT_BY_PATH(dept_name, '/') AS full_path, -- 函数直接用
CONNECT_BY_ISLEAF AS is_leaf -- 伪列直接用
FROM departments
START WITH parent_id IS NULL
CONNECT BY PRIOR dept_id = parent_id
ORDER SIBLINGS BY dept_name; -- 同层级排序也支持一句话总结：
老业务 SQL 不用动、不用改、不用重测逻辑，直接平滑迁移。
三、伪列全家桶：ROWNUM / ROWID / LEVEL 全部支持
伪列可以说是 Oracle SQL 的"灵魂"，看着像列，其实不真实存储，却无处不在。
金仓 ES V9 对核心伪列做到高度兼容，DBA 最常用的那套几乎都能直接用：
| 伪列名称 | 作用 | 金仓 ES 支持 | 典型场景 |
|---|---|---|---|
| ROWNUM | 返回结果行号 | ✅ 完全兼容 | 分页、TopN 查询 |
| ROWID | 行物理地址 | ✅ 完全兼容 | 快速去重、精准定位 |
| LEVEL | 层次查询深度 | ✅ 完全兼容 | 树形展示、层级控制 |
| CONNECT_BY_ROOT | 取层级树根节点 | ✅ 完全兼容 | 路径汇总、上级追溯 |
| ORA_ROWSCN | 行变更号 | ⚠️ 部分兼容 | 乐观锁（需配置） |
3.1 经典场景：用 ROWID 高效去重
Oracle DBA 最常用的去重手段之一，就是用 ROWID 保留一条、删除重复。
在金仓 ES 里，写法完全一样：
sql
-- 金仓 ES 直接执行：按 emp_id 去重，保留 ROWID 最小的一条
DELETE FROM emp_dup a
WHERE a.rowid > (
SELECT MIN(b.rowid)
FROM emp_dup b
WHERE a.emp_id = b.emp_id
);金仓 ES 内部有一套对应的行标识机制，遇到 ROWID 会自动映射，保证语义一致。
老的数据清洗、去重脚本，直接无缝迁移。
3.2 老式分页：ROWNUM 嵌套写法直接支持
很多老系统不用 LIMIT/OFFSET，而是用 ROWNUM 套娃分页：
sql
-- Oracle 经典分页：第 11~20 条
SELECT * FROM (
SELECT t.*, ROWNUM rn FROM (
SELECT * FROM orders ORDER BY order_date DESC
) t WHERE ROWNUM <= 20
) WHERE rn > 10;这段代码在金仓 ES 直接可运行 。
虽然它也支持标准分页，但保留 ROWNUM 能让老系统零改动上线，性价比极高。
四、迁移怎么验证？一套流程直接照做
为了让你从 Oracle 迁移到金仓 ES 更稳，这里给一套可落地的验证流程。
4.1 迁移验证流程图
是
否
是
否
一致
不一致
开始：Oracle SQL 审计
包含 CONNECT BY?
提取层次查询语句
用到 ROWNUM/ROWID/LEVEL?
金仓 ES 直接执行
提取伪列相关SQL
常规迁移流程
结果 & 执行计划对比
✅ 验证通过：代码不动
检查数据、统计信息、Hint
优化后重新比对
正式上线
4.2 性能对标怎么做？重点看这 3 点
- 执行计划对比
千万级树形数据，分别在 Oracle 和金仓 ES 执行EXPLAIN，看是否走高效索引、是否避免全表扫描。 - LEVEL 过滤效率
测试WHERE LEVEL <= 3这类条件，是否能快速剪枝、提升速度。 - ROWID 回表速度
验证通过ROWID定位数据的效率，是否接近 Oracle 水平。
实际测试中，金仓 ES V9 对层次查询做了内核优化，深层递归（超过50层）更稳定，不容易溢出，执行计划也更智能。
五、不止兼容：金仓 ES 还带来额外优势
兼容只是底线，好用才是亮点。在树形结构处理上，金仓 ES 还有不少增强：
- 错误更友好
遇到环路数据，不只支持NOCYCLE，还会输出更清晰的日志，方便 DBA 快速定位脏数据。 - 混合查询更优
层次查询 + 窗口函数、JSON、子查询混用，优化器能做全局代价估算，支持谓词下推，性能更稳。 - GIS + 层级更强大
省市区街道这类"空间+层级"场景，可以在CONNECT BY里直接走空间索引，Oracle 要实现类似效果成本更高。
六、结语：国产化替代，真的可以不用那么焦虑
数据库迁移最难的，从来不是增删改查，而是那些沉淀多年、带明显数据库"方言"的复杂 SQL。
CONNECT BY、LEVEL、ROWNUM、ROWID 就是 Oracle 最典型的一批。
金仓 ES V9 不是简单"模拟语法"，而是在内核层重构了层次查询引擎和伪列机制：
- 对开发：不用学新语法，不用重写存储过程
- 对 DBA：不用改去重、分页、树形查询脚本
- 对企业：迁移成本大幅下降，项目周期明显缩短
告别迁移焦虑，不是口号，是靠实实在在的内核兼容做支撑。
当你下一条 START WITH ... CONNECT BY 在金仓 ES 里丝滑跑起来时，你会发现：
国产化替代的路，比想象中更平稳、更简单。