数据库兼容性测试怎么做：从语法扫描到上线验收

数据库迁移项目里，“兼容某数据库”只能说明方向，不能直接成为上线结论。真正需要回答的是：现有对象要改多少、相同 SQL 是否返回相同结果、并发行为会不会变化，以及目标库能否在真实负载下满足延迟与成本要求。

因此，数据库兼容性测试不应只有一张“通过率”报表，而应拆成语法、数据与语义、事务并发、性能与运维四条验证线。每条线都要有输入、执行方法、证据和验收阈值，最终才能形成可签字的 POC 结论。

先定义兼容范围，再选择测试方法

“兼容”至少包含四个层面：

测试前先确定源库版本、目标库版本、字符集、排序规则、驱动版本、连接池配置和部署拓扑。版本或参数不同，结果就可能不同；如果测试环境与生产环境差距过大，即使 SQL 全部执行成功，也不足以证明可以安全迁移。

还要按业务重要性给对象和 SQL 分级。例如，支付、库存、账户余额属于核心路径，报表查询和历史归档属于一般路径。兼容率必须带权重看：一个核心存储过程失败，可能比数百个低频查询需要改写更重要。

第一层：扫描语法和数据库对象

这一阶段的目标不是追求一个漂亮的百分比，而是形成准确的改造工作量清单。

建议收集以下材料：

• 表、索引、视图、序列、触发器和分区定义；
• 存储过程、函数、包、事件与定时任务；
• 生产环境具有代表性的 SQL 样本；
• ORM 生成的 SQL、批处理脚本和运维脚本；
• 驱动、连接协议以及应用使用的数据库特性。

扫描后应把结果分为三类：原样可用、可自动转换、必须人工改写。不要只记录数量，还要记录对象名称、调用链、业务等级、预计改造方式和负责人。

以 Oracle 迁移到 MySQL 或兼容数据库为例，DECODE、NVL、旧式外连接、序列、包和过程语言都可能需要处理。简单函数通常可以改成标准表达式，但包含动态 SQL、异常处理或复杂事务控制的存储过程，评估成本不能只按代码行数计算。

-- 专有表达式改写为更通用的 CASE
SELECT CASE status
         WHEN 1 THEN '启用'
         WHEN 2 THEN '停用'
         ELSE '未知'
       END AS status_name
FROM orders;

数据类型也要逐列核对。数值精度、字符长度单位、日期与时间戳、时区、大对象、无符号整数和布尔值的映射，都可能在迁移后改变约束或计算结果。最终报告应能回答“哪些地方必须改、由谁改、怎么回归”，而不只是“转换成功了多少”。

第二层：用边界数据验证结果语义

SQL 能执行不代表结果相同。语义测试应使用确定的边界数据，在源库与目标库执行同一组用例，并对结果集做规范化后逐项比较。

Oracle Database 会把零长度字符值按 NULL 处理，而 MySQL 中空字符串与 NULL 是不同值。这类差异可能影响条件判断、唯一性规则、字符串拼接和统计结果。因此，用例至少要覆盖：

• NULL、空字符串和只包含空格的字符串；
• 0、负数、最大值、最小值和小数精度边界；
• 超长字符、多字节字符、大小写和重音字符；
• 月末、闰日、夏令时切换点和不同时区；
• 重复键、唯一约束、默认值和自增值；
• 聚合、排序、分页及 NULL 排序位置。

SELECT COUNT(*) FROM customer WHERE nickname = '';
SELECT COUNT(*) FROM customer WHERE nickname IS NULL;

两条语句在不同数据库上的关系不能靠经验推断，应在目标版本和目标参数下验证。

隐式类型转换同样需要重点测试。MySQL 官方文档明确说明，不同类型参与比较时会发生类型转换；字符串列与数字比较还可能无法利用该列索引。迁移时应把模糊比较改为类型一致的表达式，并检查执行计划，而不是只确认返回结果。

-- customer_no 为字符列时，参数也应按字符类型绑定
SELECT * FROM customer WHERE customer_no = ?;

应用侧最好使用参数化查询并显式绑定类型。差异比对时，还应统一时间格式、浮点精度和结果排序，避免把展示格式差异误判为数据错误，或把真正的精度损失隐藏掉。

第三层：验证事务隔离、锁和故障行为

并发语义往往是迁移风险的集中区。Oracle Database 默认采用 READ COMMITTED；MySQL InnoDB 默认采用 REPEATABLE READ。两者在读取快照、锁范围和并发控制上的行为并不相同，应用如果隐含依赖了源库默认值，迁移后可能出现难以在单线程测试中发现的问题。

建议建立“隔离级别 × 业务操作”的测试矩阵，至少覆盖：

• 两个事务同时更新同一行；
• 范围查询期间插入满足条件的新行；
• 先查询后更新的读改写流程；
• 唯一键冲突和批量写入；
• 长事务与短事务并发；
• 死锁后的重试与幂等处理；
• 连接中断、主备切换和事务回滚。

每个用例都要记录会话步骤、隔离级别、等待时间、锁信息、错误码和最终数据。只说“没有报错”是不够的，还应验证阻塞是否在预期时间内解除、失败事务是否完整回滚、重试是否会重复扣款或重复写入。

-- MySQL 查看当前会话隔离级别
SELECT @@transaction_isolation;

连接池也是测试对象。需要确认自动提交、事务超时、空闲连接回收、会话变量初始化和故障连接剔除是否正确。很多迁移问题并非数据库内核不兼容，而是驱动或连接池默认行为发生了变化。

第四层：用真实负载验证性能与可运维性

性能兼容不等于跑出相同的峰值 TPS。更有意义的问题是：在相同数据规模、并发模型和业务比例下，目标库的吞吐、长尾延迟和资源消耗是否落在可接受范围内。

压测模型应尽量来自生产观测，包括读写比例、热点键、事务长度、SQL 分布和高峰时段。通用基准可以用于建立基线，但不能替代业务 SQL 回放。至少持续记录：

• 吞吐量和成功率；
• 平均、P95、P99 延迟；
• CPU、内存、磁盘 IOPS、吞吐和延迟；
• 缓存命中率、连接数、锁等待和死锁；
• 执行计划变化与慢 SQL 分布；
• 同等负载下的实例规格和存储成本。

测试应包含预热、稳态和压力提升阶段。只截取短时间峰值容易掩盖缓存抖动、检查点、日志刷盘、存储突发额度耗尽等问题。验收阈值应由现网基线和业务服务等级目标推导，而不是照抄固定比例。

数据库上线后还需要可维护，所以 POC 应加入备份恢复、时间点恢复、监控告警、审计、扩缩容和故障切换演练。若恢复时间目标无法满足，或者故障切换后应用不能自动恢复连接，即便查询性能达标，也不能算迁移准备完成。

把 POC 变成可签字的验收清单

一份可执行的数据库兼容性测试计划，可以按以下顺序推进：

1. 建立资产基线：冻结版本、参数、对象数量、数据规模和 SQL 样本范围。
2. 完成静态评估：输出对象级改写清单，并标记业务等级。
3. 迁移代表性数据：校验行数、校验和、约束及增量同步延迟。
4. 执行语义差异用例：比较边界值、日期、字符集和类型转换结果。
5. 执行并发与故障用例：验证隔离、锁、重试、回滚和切换行为。
6. 进行业务负载压测：比较吞吐、长尾延迟、资源与成本。
7. 演练恢复和回退：测量恢复时间，确认回退路径和数据处理方案。
8. 形成风险闭环：每项差异都有责任人、修复方案、复测证据和接受人。

验收指标应写成可测量的条件，例如：核心对象全部完成迁移或改写；关键业务用例结果一致；高优先级 SQL 执行计划已经复核；P99 延迟符合业务目标；备份恢复在约定窗口内完成。具体数值必须来自本系统基线，不能由厂商宣传材料代替。

同时保留“已知差异清单”。并非所有差异都必须消除，有些可以通过应用改造、参数调整或操作规程规避，但风险接受需要由业务、研发和运维共同确认。

哪些团队尤其需要做完整验证

以下场景不适合只做语法扫描：

• 大量使用存储过程、触发器或数据库专有特性；
• 涉及支付、账务、库存等强一致业务；
• 存在高并发热点更新或长事务；
• 跨数据库品牌或跨兼容模式迁移；
• 对停机窗口、恢复点和恢复时间有明确要求；
• 计划把自建数据库迁到云数据库，并同时改变版本、拓扑或存储类型。

如果系统规模较小，也可以缩小样本，但不应省略关键路径、边界语义、并发和恢复验证。资源有限时，优先把测试投入到故障后果大、调用频率高、改造复杂的对象和 SQL 上。

结论

数据库兼容性测试的价值，不是证明某个产品“百分之百兼容”，而是把迁移中的未知项变成可定位、可复测、可验收的工程问题。

语法扫描用于估算改造量，边界用例用于确认结果正确，并发测试用于识别事务与锁风险，业务压测和恢复演练用于判断系统能否稳定运行。只有这些证据共同成立，“兼容”才具备上线决策意义。