Oracle国产化替代时，怎样盘点PL/SQL、包、序列和复杂SQL的改造量？
Oracle 国产化替代的第一步，不是选数据库，而是搞清楚要改多少东西。PL/SQL 存储过程、包（Package）、序列（Sequence）、复杂 SQL——这些 Oracle 特有的对象和语法，是迁移评估中最耗时的部分。
从哪里开始盘点？
存储过程和函数
先统计数量和代码行数。但光看数量不够，需要按复杂度分类：
- 简单： 纯 SQL 操作，不涉及游标、动态 SQL、异常处理
- 中等： 包含条件分支、循环、游标
- 复杂： 涉及动态 SQL 拼接、自治事务、DBMS_* 调用
- 极难： 使用了 UTL_FILE、UTL_HTTP、UTL_SMTP 等外部包调用
包（Package）
Oracle 的 Package 把相关的存储过程、函数、变量组织在一起，包含规范（Specification）和包体（Body）。迁移时需要确认目标数据库是否支持类似的模块化组织方式。如果不支持，需要拆散为独立的存储过程和函数，同时处理包级变量的作用域问题。
序列（Sequence）
Oracle 的 Sequence 是独立对象，可以被多个表引用。不同数据库的替代方案不同：MySQL 使用 AUTO_INCREMENT（表级绑定），PostgreSQL 支持 SEQUENCE 对象。如果业务中多个表共享同一个序列，迁移时需要特别处理。
复杂 SQL
需要重点检查的 SQL 特性：
- 层次查询（CONNECT BY）： Oracle 特有语法，标准 SQL 用递归 CTE 替代
- 分析函数（Analytic Functions）： 大部分现代数据库都支持，但边界情况有差异
- MERGE 语句： Oracle 的 MERGE 语法和标准 SQL 有细节差异
- WITH 子句（CTE）： 大部分数据库支持，但递归 CTE 的深度限制不同
- flashback 查询、PIVOT/UNPIVOT 等 Oracle 特有语法
评估方法
第一步，用工具做自动化扫描。 Oracle 的数据字典（USER_SOURCE、USER_PROCEDURES 等）可以导出所有 PL/SQL 对象。结合语法分析工具，可以初步识别不兼容的语法点。
第二步，按业务影响排优先级。 不是所有 PL/SQL 都需要迁移第一天就改完。核心交易链路上的优先处理，报表和辅助功能可以延后。
第三步，估算改造工作量。 简单和中等复杂度的存储过程，通常可以做语法翻译；复杂和极难的，可能需要重新设计逻辑。
TiDB 在 Oracle 兼容性评估中的对应能力
TiDB 兼容 MySQL 协议，更适合数据迁移和基础兼容性检查。对于 PL/SQL 的改造量评估，建议使用 Oracle 数据字典导出所有存储过程和包的清单，再结合目标数据库的语法兼容文档逐项比对。TiDB 从 v6.2 开始支持存储过程（兼容 MySQL 语法），可以作为部分逻辑的改写目标。
如果你正在做 Oracle 国产化替代的可行性评估，建议先从存储过程和包的复杂度盘点开始，量化改造工作量后再进入数据库选型阶段。