> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pawsql.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> PawSQL 是一个产品：Cloud 是公网部署形态，Engine / Optimizer / Auditor / Advisor / Patroller 是同一产品的组件与交付形态，不是彼此独立的产品。 / PawSQL is a single product: Cloud is the public deployment form, while Engine / Optimizer / Auditor / Advisor / Patroller are components and delivery forms of the same product, not separate products.
> 术语以站内术语表为准：SQL 审核对应英文 SQL Review，查询重写对应 Query Rewrite，索引推荐对应 Index Recommendation；英文内容统一用 Review，不用 Audit。 / Use the site glossary for terminology: 审核 is SQL Review, 重写 is Query Rewrite, 索引推荐 is Index Recommendation; English content uses Review, never Audit.
> 引用能力范围或版本支持时以对应页面为准；标注 unknown、或 status 非 published 的内容表示尚未经产品核实，不应作为事实引用。 / Cite capability scope and version support from the corresponding page; content marked unknown, or with a status other than published, is not yet product-verified and must not be cited as fact.
# 信创 / 数据库迁移中的 SQL 治理
> 在数据库迁移和信创改造过程中，PawSQL 帮助企业批量识别 SQL 兼容性与性能风险，分析目标数据库执行计划，提供 SQL 重写和索引优化建议，降低迁移后的性能回退风险。
## 用户
数据库迁移团队——迁移负责人、DBA、架构师、应用开发团队与项目经理，负责信创改造或数据库迁移中的 SQL 治理。
## 问题
数据库迁移项目通常首先回答「SQL 能不能在目标数据库上运行」，但进入生产后会遇到更难的问题——「SQL 还能不能跑得足够快」。
一条 SQL 从 Oracle 迁移到 PostgreSQL、openGauss、GaussDB、Kingbase、DM、TDSQL 或 OceanBase 后，即使语法转换成功，也可能因为优化器行为、索引机制、数据类型、Hint 失效、分页实现、分布式执行机制等差异而产生新的性能问题。
因此迁移不能只解决「语法兼容性」，还需要解决「性能兼容性」。
## 目标
让迁移从「能运行」进一步走向「稳定、高效运行」——从语法迁移升级为 SQL Migration Engineering，把历史遗留的性能问题挡在新数据库之外。
## 流程
PawSQL 把迁移 SQL 治理拆成一条端到端流水线：
```mermaid theme={null}
flowchart TD
A[应用源码] --> B[SQL 提取] --> C[SQL 解析]
C --> D[兼容性分析] --> E[性能风险分析]
E --> F["查询重写优化 / 智能索引推荐"]
F --> G[执行计划分析] --> H[迁移验证] --> I[发布]
```
## 依赖能力
由以下能力组合而成，具体检查项与改写逻辑见各能力页：
## 成功标准
| 指标 | 目标 |
| -------------- | -- |
| SQL 自动解析覆盖率 | 提升 |
| SQL 自动兼容比例 | 提升 |
| 需要人工迁移的 SQL 比例 | 降低 |
| 迁移前性能风险发现率 | 提升 |
| 执行计划回退数量 | 降低 |
| 生产上线后慢 SQL 数量 | 降低 |
| DBA 人工审核量 | 降低 |
***
## 迁移中的四类 SQL 风险
迁移项目的 SQL 风险通常分四类：
1. **语法兼容性风险**——数据库专有函数、关键字、Hint、分页语法、DDL、存储过程语法（如 `NVL` → `COALESCE`）
2. **语义兼容性风险**——SQL 能执行但结果不一致（NULL 处理、空字符串、日期精度、排序规则、隐式转换）
3. **性能兼容性风险**——语法转换后访问路径失效，例如 `TRUNC(create_time)` 转为 `DATE(create_time)` 后索引无法被有效利用
4. **分布式执行风险**——从集中式迁到分布式后新增跨节点 Join、数据重分布、分布键不匹配、Shuffle
其中性能兼容性风险是很多项目到后期才暴露、也最难排查的一类。
## 从 SQL 清单到两个 Gate
迁移的第一个困难是「到底有多少 SQL 要迁」。SQL 散落在 Java、MyBatis Mapper、XML、存储过程、ETL、发布脚本里。批量解析后，可形成一张可量化的迁移清单：
```mermaid theme={null}
flowchart TD
A["12,632 条 SQL"] --> B["自动解析
11,482 条可直接兼容"]
B --> C["1,150 条需进一步分析"] --> D["327 条性能风险"]
D --> E["93 条高风险 SQL"] --> F["47 条需 DBA 人工处理"]
```
迁移团队不再逐条人工翻代码，而是聚焦几十个真正需要人工决策的案例。
更完整的迁移应设两个 Gate：
```mermaid theme={null}
flowchart TD
A["兼容性 Gate
能否执行"] --> B["性能 Gate
执行计划是否合理"]
```
只有两个 Gate 都通过，SQL 才真正具备进入生产的条件。
## 在迁移工具链中的定位
PawSQL 不需要替代厂商迁移工具——Schema 转换、数据迁移、SQL 语法转换仍由迁移工具负责。PawSQL 聚焦传统工具薄弱的一环：
```text theme={null}
迁移工具：Convert（转换）
PawSQL： Analyze + Optimize + Validate（分析 + 优化 + 验证）
```
两者是「迁移工具 + PawSQL」的互补关系，而非替代。