>十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。


----

干 DBA 十几年，我见过太多数据库迁移项目死在一个环节上：SQL 兼容性。

项目启动，定好迁移窗口，数据导过去，应用一切——跑不起来。为什么？存储过程语法不兼容、Oracle 的 DECODE 函数目标库没有、MySQL 的反引号在 PostgreSQL 里是保留字符、一条关键的动态 SQL 在新库里执行计划完全变了。

这些问题不是技术解决不了，是**迁移前没做 SQL 审计**。不知道存量 SQL 有多少、不知道哪些语法不兼容、不知道哪些要改、改多少——上线那天就是开盲盒。

今天把迁移前 SQL 审计的完整流程讲清楚。从存量 SQL 采集、分类评估、兼容性扫描到风险分级。跟着这个流程走一遍，迁移上线那天心里有数。


----

## 01 存量 SQL 采集：你到底有多少 SQL 要审


不做 SQL 审计的第一步错误是：不知道要审什么。

很多项目的做法是"让开发把应用里的 SQL 都理出来"。结果呢？开发说"这个模块是前人写的我不清楚"、"SQL 是拼接的动态语句不在代码里"、"存储过程在数据库里跑了五年没人知道它干了什么"。

靠人理 SQL 是不靠谱的。要靠数据库自己告诉你。

### 采集路径一：慢查询日志


慢查询日志是最基础的采集源。所有超过阈值的 SQL 都会被记录。

MySQL：

```
-- 开启慢查询日志
SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;  -- 超过1秒的记录
SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log';
```
PostgreSQL/KES：

```
-- postgresql.conf
log_min_duration_statement = 1000  -- 超过1000ms的记录
log_statement = 'none'             -- 不记录所有语句，避免日志过大
```
**问题**：慢查询只记录了慢 SQL，不慢但语法不兼容的 SQL 不会被记录。所以慢查询日志只是采集的一部分。

### 采集路径二：全量 SQL 抓取


如果需要审计所有 SQL（不只是慢的），需要开启全量 SQL 日志。

MySQL：

```
-- 开启 general log（注意：生产环境谨慎开启，日志量很大）
SET GLOBAL general_log = 'ON';
SET GLOBAL general_log_file = '/var/log/mysql/general.log';
```
PostgreSQL/KES：

```
-- postgresql.conf
log_statement = 'all'  -- 记录所有SQL
```
**踩坑提醒**：全量日志开启后，日志量可能达到每天几 GB 甚至几十 GB。**只开必要的采集窗口**，比如业务高峰期开 2-4 小时，收集到的 SQL 基本能覆盖 90% 以上的热点 SQL。不需要 7×24 开。

### 采集路径三：应用层埋点


如果应用用了 ORM（MyBatis、Hibernate、JPA），可以在应用层加 SQL 拦截器，记录实际发出的 SQL。

MyBatis 示例：

```
@Intercepts({
    @Signature(type = StatementHandler.class,
               method = "prepare",
               args = {Connection.class, Integer.class})
})
public class SqlAuditInterceptor implements Interceptor {
    @Override
    public Object intercept(Invocation invocation) throws Throwable {
        StatementHandler handler = (StatementHandler) invocation.getTarget();
        String sql = handler.getBoundSql().getSql();
        // 记录 SQL 到审计日志
        log.info("[SQL Audit] {}", sql);
        return invocation.proceed();
    }
}
```
### 采集后的处理


不管从哪个路径采集到 SQL，都需要做一步**去重和归一化**：

```
-- 原始SQL
SELECT * FROM users WHERE id = 123;
SELECT * FROM users WHERE id = 456;
SELECT * FROM users WHERE id = 789;

-- 归一化后（参数替换为占位符）
SELECT * FROM users WHERE id = ?;
```
归一化之后再去重，得到的是 SQL 模板的数量，而不是参数不同导致的"伪重复"。这一步不做好，你会以为有十万条 SQL 要审，实际可能只有几百个模板。


----

## 02 SQL 分类评估：不同类型改造难度完全不同


采集到 SQL 之后，按类型分类。不同类型的 SQL，迁移改造难度差异巨大。

### 分类维度


|类型|占比（经验值）|改造难度|说明|
|:-:|:-:|:-:|:-:|
|简单 DQL（SELECT）|40-60%|低|大多数标准 SQL 语法跨库兼容|
|DML（INSERT/UPDATE/DELETE）|20-30%|低-中|基础语法兼容，注意自增列、默认值差异|
|DDL（CREATE/ALTER）|5-10%|中|数据类型、索引语法、分区表语法差异|
|存储过程/函数|5-15%|高|PL/SQL、T-SQL 与 PL/pgSQL 差异大|
|触发器|2-5%|高|触发时机、NEW/OLD 引用语法差异|
|视图|3-8%|中|大部分兼容，注意特有函数|
|动态 SQL（拼接生成）|10-20%|中-高|需要在应用层改造拼接逻辑|

**踩坑提醒**：存储过程和触发器是迁移的最大雷区。一个 Oracle 的存储过程可能有上千行，涉及游标、异常处理、动态 SQL、包体——改到 PostgreSQL 的 PL/pgSQL 或者 MySQL 的存储过程语法，几乎等于重写。

### 实测：某项目的 SQL 分类结果


一个实际项目的审计结果（Oracle → 国产库）：

```
总 SQL 模板数：1,847 条

简单 DQL：    923 条（50.0%）  → 直通，无需修改
DML：        486 条（26.3%）  → 32 条需要微调（日期函数差异）
DDL：        112 条（6.1%）   → 28 条需要修改（数据类型映射）
存储过程：    187 条（10.1%）  → 142 条需要重写（语法差异）
触发器：      43 条（2.3%）    → 38 条需要重写
视图：        56 条（3.0%）    → 15 条需要微调
动态 SQL：     40 条（2.2%）    → 全部需要应用层改造

直通率（无需修改）：50.0%
微调率（小改可兼容）：4.5%
重写率（改造量大）：   18.8%
```


----

## 03 兼容性扫描：逐条过，不放过任何差异


分类之后，要对每一条 SQL 做兼容性扫描。不是"大概看看"，是逐条检查语法、函数、数据类型。

### 扫描维度


**语法差异**：


- Oracle 的 `SYSDATE` → PostgreSQL 的 `CURRENT_DATE` / MySQL 的 `NOW()`

- MySQL 的反引号 `\`column\`` → 标准 SQL 双引号 `"column"`

- Oracle 的 `NVL()` → PostgreSQL/MySQL 的 `COALESCE()`

- SQL Server 的 `TOP 10` → PostgreSQL/Oracle 的 `LIMIT 10` / `FETCH FIRST 10 ROWS`


**函数差异**：


- 字符串函数：`SUBSTR` / `SUBSTRING` / `MID`

- 日期函数：`TO_CHAR` / `DATE_FORMAT` / `TO_DATE`

- 聚合函数：`GROUP_CONCAT`（MySQL）→ `STRING_AGG`（PostgreSQL）

- Oracle 特有：`DECODE`、`WM_CONCAT`、`LISTAGG`


**数据类型差异**：


- Oracle `NUMBER` → PostgreSQL `NUMERIC` / MySQL `DECIMAL`

- Oracle `VARCHAR2` → PostgreSQL `VARCHAR` / MySQL `VARCHAR`

- Oracle `CLOB` → PostgreSQL `TEXT` / MySQL `LONGTEXT`

- SQL Server `DATETIME` → PostgreSQL `TIMESTAMP`


**自增列差异**：


- MySQL `AUTO_INCREMENT` → PostgreSQL `SERIAL` / `GENERATED ALWAYS AS IDENTITY`

- Oracle 序列 → PostgreSQL 序列（兼容） / MySQL 8.0 无原生序列


### 扫描工具


不要人工逐条看。用工具做初步扫描：


- **开源方案**：ora2pg（Oracle → PostgreSQL 迁移评估）、pgloader（自动转换）

- **商业方案**：各数据库厂商的迁移评估工具。以金仓的迁移评估工具为例，用法比较直接——指定源库连接信息，工具自动采集源库的 SQL、存储过程、表结构，然后逐条与目标库的兼容性做比对，最终输出一份分级报告：哪些能直通、哪些要改语法、哪些要重写。好处是自动化程度高，不用自己写扫描脚本，而且报告格式清晰，直接拿来给项目组做工期评估。

- **自研脚本**：用正则匹配常见不兼容语法（函数名、保留字、特殊语法）


>实测建议：工具扫描只能发现"显式"的语法差异，"隐式"的差异（比如执行计划变化、隐式类型转换行为不同）需要实际在目标库上跑一遍验证。


----

## 04 风险分级：直通、微调、重写、不支持


扫描完之后，按改造难度把每条 SQL 分四档：


|等级|定义|改造工作量|处理方式|
|:-:|:-:|:-:|:-:|
|**直通**|标准 SQL 语法，目标库完全兼容|0|直接迁移，无需修改|
|**微调**|个别函数/语法需要替换|每条 5-30 分钟|批量替换函数名，验证后即可|
|**重写**|语法结构差异大，或涉及业务逻辑|每条 1-8 小时|逐条分析、重写、单元测试、集成测试|
|**不支持**|目标库完全不支持的特性|需架构调整|评估替代方案，或保留原库|

### 基于分级估算迁移工期


用上面的项目数据举例：

```
直通：923 条 → 0 人天（自动迁移）
微调：83 条  → 83 × 0.5h = 41.5 人时 ≈ 5 人天
重写：180 条 → 180 × 4h = 720 人时 ≈ 90 人天
不支持：0 条 → 0 人天

总计：约 95 人天
```
这就是"心中有数"。没做审计之前，你可能以为"一千多条 SQL，几个人一周就搞定了"。审计之后才知道，实际要三个月。

**踩坑提醒**：重写工作量的估算一定要留 buffer。存储过程的重写往往比预期多 30-50%，因为里面藏着的业务逻辑比表面看起来复杂。


----

## 对比：迁移前做 SQL 审计 vs 不做


|维度|不做SQL审计|做SQL审计|
|:-:|:-:|:-:|
|迁移风险|开盲盒，上线那天才知道问题|提前暴露，分级处理|
|工期预估|拍脑袋，经常延期 2-3 倍|基于数据估算，偏差 < 30%|
|上线事故|高概率出现 SQL 报错、性能下降|提前验证，上线当天问题可控|
|回退概率|高（发现不兼容只能回退）|低（不兼容的提前处理了）|
|团队信心|上线前焦虑，上线后救火|按节奏推进，心中有数|
|客户信任|一次事故，信任归零|平稳迁移，信任加分|


----

## 决策框架：你的项目需要多深入的 SQL 审计？


**轻量级（SQL 数量 < 500，以简单 CRUD 为主）**：


- 采集慢查询日志 + 全量日志 2 小时

- 工具扫描 + 人工抽检 20%

- 重点关注存储过程和触发器

- 工期估算：1-2 周


**标准级（SQL 数量 500-5000，有存储过程/复杂查询）**：


- 采集全量日志 4-8 小时（分时段）

- 逐条工具扫描 + 人工复核所有非直通项

- 存储过程和触发器逐条在目标库验证

- 工期估算：1-3 个月


**深度级（SQL 数量 > 5000，大量存储过程/动态 SQL/复杂业务逻辑）**：


- 采集全量日志 + 应用层埋点（确保覆盖率 > 95%）

- 逐条扫描 + 逐条目标库验证

- 建立自动化回归测试（每条 SQL 在目标库跑一遍比对结果）

- 工期估算：3-6 个月以上


----

## 态度转变：我以前也不做


说实话，干 DBA 前五年，我做迁移项目也不做 SQL 审计。

原因很简单：觉得麻烦。数据迁移有工具，网络连通有方案，应用部署有流程——偏偏 SQL 审计又慢又细，一条一条看，像在做手工活。开发也说"大部分 SQL 都是标准语法，应该没问题"。

直到有一次 Oracle → MySQL 的迁移。上线当天，凌晨两点开始切流量，三点开始报错——一个关键的报表存储过程用了 Oracle 的 `CONNECT BY` 递归查询，MySQL 8.0 之前不支持。回退。第二次上线，又发现三处日期函数不兼容。再回退。第三次才过。

那次之后，我做任何迁移项目，第一件事就是 SQL 审计。不是因为"流程要求"，是因为"吃过亏"。


----

## 深度分析：为什么 SQL 兼容性比想象中难？


很多人以为"SQL 是标准，各家数据库应该差不多"。

事实上，SQL 标准（SQL:2003、SQL:2008、SQL:2016）只是一个子集。各家数据库在标准之上加了自己的扩展：Oracle 有 PL/SQL 和大量内置函数，MySQL 有特有的语法糖和存储引擎特性，PostgreSQL 有严格的标准兼容和 PL/pgSQL，SQL Server 有 T-SQL。

**真正的兼容性不是"SQL 能不能跑"，是"跑出来结果对不对、性能能不能接受"**。

一条 SQL 在源库跑 0.1 秒，目标库跑 10 秒——语法上完全兼容，但业务上不可用。这种"隐性不兼容"是最难发现的，只能在目标库上实际执行验证。

所以 SQL 审计不只是"语法扫描"，是"语法扫描 + 目标库执行验证 + 性能比对"三件套。少任何一个，都是不完整的。


----

## 迁移前 SQL 审计检查清单


### 采集阶段


- 确认采集窗口覆盖业务高峰和低谷

- 开启全量 SQL 日志（控制时长，避免磁盘打满）

- 应用层埋点（ORM 项目）

- SQL 归一化去重，得到模板数量

- 确认覆盖率 > 90%（对比应用代码中的 SQL 引用）


### 分类阶段


- 按 SQL 类型分类（DQL/DML/DDL/存储过程/触发器/视图/动态 SQL）

- 标记每个类型的预估改造难度

- 重点关注存储过程和触发器（高风险）


### 扫描阶段


- 工具扫描语法差异（函数名、保留字、特殊语法）

- 数据类型映射检查

- 自增列/序列处理方案确认

- 动态 SQL 的应用层改造点确认


### 验证阶段


- 在目标库上逐条执行非直通 SQL

- 比对执行结果（数据一致性）

- 比对执行计划/性能（性能不低于源库的 80%）

- 记录所有不兼容项和改造方案


### 工期评估


- 按风险分级估算工作量

- 留出 30-50% buffer（存储过程/复杂逻辑）

- 确认迁移窗口时间是否够

- 准备回退方案


----

## 总结


数据库迁移，数据迁移只是最基础的一步。真正决定成败的是 SQL 兼容性。

不做 SQL 审计直接迁移 = 开盲盒。做了 SQL 审计 = 按图施工。

流程是：采集（慢查询 + 全量日志 + 应用埋点）→ 分类（按 SQL 类型）→ 扫描（语法/函数/数据类型）→ 分级（直通/微调/重写/不支持）→ 验证（目标库执行比对）→ 估工期。

每一步都别省。省掉的每一步，上线那天都会以事故的形式还给你。

后续我会继续分享**数据库压测实战、容量规划**这些话题，跟着我一篇篇学，数据库这块就没问题了。

有问题评论区见。


----

十五年数据库领域老炮。关注我，一起把数据库这件事搞明白。

十五年数据库相关经验，做过 DBA、架构师、技术顾问。不求"颠覆"，只求"靠谱"。

数据库迁移 SQL 审计实战：从"开盲盒"到"心中有数"的方法论

数据库迁移项目失败的最大风险是 SQL 不兼容。完整梳理迁移前 SQL 审计流程：通过慢查询日志、全量日志、应用埋点采集存量 SQL，按类型分类评估，逐项扫描语法/函数/数据类型差异，分四档风险分级（直通/微调/重写/不支持），基于数据估算迁移工期。不做审计=开盲盒，做了=按图施工。

数据库

运维

后端

数据库迁移失败多因SQL兼容性问题，迁移前必须做完整SQL审计。核心流程包括：采集存量SQL（慢查询+全量日志+应用埋点）、按类型分类评估改造难度、逐条兼容性扫描、按直通/微调/重写/不支持分级、在目标库实际执行验证并估算工期。不做审计就是开盲盒，做了才能心中有数，确保上线平稳。

数据一致性

单元测试

数据迁移

集成测试

回归测试

代码解释

PostgreSQL

MySQL

腾讯云数据库特惠，新用户首单0.5折起


sqlserver

2026上云采购 | AI焕新·智启新局

腾讯云BI特惠9.9元起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

数据库迁移 SQL 审计实战：从"开盲盒"到"心中有数"的方法论-腾讯云开发者社区-腾讯云

数据库迁移 SQL 审计实战：从"开盲盒"到"心中有数"的方法论

数据库迁移 SQL 审计实战：从"开盲盒"到"心中有数"的方法论

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐