从SQL Server到OceanBase：手游核心库迁移实战与避坑指南-开发者社区

去年下半年我们团队接到一个挺实际的活：帮一家马来西亚手游公司把核心数据库从 SQL Server 迁到 OceanBase。这家公司产品主要在东南亚发行，休闲游戏为主，日活几十万，后端有玩家账号、充值流水、排行榜、礼包码、运营后台一大堆业务全都压在 SQL Server 上。评估完现状之后我们发现，这不是一次简单的“导出再导入”，里面涉及兼容性改造、增量同步、割接切换、回滚预案，甚至还要和吉隆坡那边的运维同事跨时区配合。这篇就把我们当时的完整思路和执行过程写出来，给正在做同类国产数据库迁移的团队一个参考。

1. 从 SQL Server 出走：马来西亚游戏业务的三个真实痛点

1.1 并发写入瓶颈与排行榜查询卡顿

这家公司的游戏业务有一个很典型的东南亚特征：现金玩家占比高，充值接口在晚上和节假日会出现很明显的峰值。SQL Server 在单机架构下跑得还算稳定，但到了晚间活动时段，玩家同时写充值流水、更新钱包余额、刷新排行榜，几个大表的锁竞争一下子就上来了。我们当时抓到的瓶颈主要集中在三张表：recharge_order（充值订单）、player_balance（玩家余额）、leaderboard_daily（每日排行榜）。

排行榜尤其痛苦。SQL Server 的普通索引在千万级行数下做“全局排名查询”时，计算成本很高，运营要看的又是实时排名，经常是一条 SQL 打过来，几个从库 CPU 同时飙到 80% 以上。用过 SQL Server 的同学都知道，这种情况不是加索引能彻底解决的，ROWNUMBER() OVER全表排序的成本摆在那里。我们试过用汇总表、缓存中间层，但最终还是觉得必须从引擎层面换一种思路。

1.2 许可证成本与扩容限制

马来西亚分公司和国内母公司走的是统一财务口径，SQL Server 的许可证费用每年都在涨。更麻烦的是，核心库跑在云上 Windows 虚拟机里，规格受限于单台机器的 CPU 和内存上限；想要横向扩展就得做 AlwaysOn 可用性组，操作复杂度高，而且对网络延迟敏感。东南亚几个机房的网络链路本身就不是特别稳定，跨地域同步经常出现日志分发延迟，运维同学半夜被叫起来处理同步中断的次数太多了。

我们评估过把架构改为“分库分表 + 读写分离”，但按当时的团队规模和运维人力，这套方案要自己处理分布式事务、全局 ID 生成、跨库 JOIN，代价太高。于是目标慢慢锁定到了 OceanBase 上——它原生就是分布式架构，可以横向扩展，同时兼容 MySQL 协议，应用侧改造相对可控。

1.3 备份恢复窗口过长

这是压垮骆驼的最后一根稻草。当时核心库全备一次要 6 小时以上，日志备份每 15 分钟一断，恢复演练时目标恢复时间要按小时算。游戏业务对数据一致性要求极高，一旦出问题，玩家充值的钱丢了可不是小事。OceanBase 在这块的优势是物理备份与多副本机制，以及基于日志的实时恢复能力，至少能让我们把恢复目标压缩到分钟级。综合这几个原因，项目正式立项，目标是在四个月内完成从 SQL Server 到 OceanBase 的迁移。

2. 迁移前必须做的“兼容性摸底”：一张清单走天下

2.1 目标端模式选型：OceanBase MySQL 模式

很多人一上来就问“OceanBase 不是兼容 Oracle 吗”，实际上 OceanBase 支持 MySQL 和 Oracle 两套模式。我们这次选的是 MySQL 模式，原因是业务团队对 MySQL 的生态更熟悉，Java 后端连接 MySQL 的工具链、监控、运维经验都可以直接复用。

选型确定之后，第一件事不是动手迁移，而是把现有 SQL Server 库里的对象完整盘点一遍。我们当时梳理出来的对象包括：几百张业务表、两百多个存储过程、几十个视图、十来个触发器，还有若干作业任务（SQL Server Agent Job）。这里面最耗时间的不是表，是存储过程和视图里的 T-SQL 写法。很多历史代码是早几任开发留下来的，里面充斥着WITH (NOLOCK)、GETDATE()、ISNULL()、CONVERT()、TOP这类 SQL Server 专属语法，迁到 MySQL 模式全部要改。

2.2 数据类型和函数差异对照

我们做了个简单的对照表给开发团队，每迁一个存储过程就对着表改，效率提高很多。这里贴一份核心对照：

SQL Server	OceanBase（MySQL 模式）	备注
`INT`/`BIGINT`	`INT`/`BIGINT`	直接兼容
`NVARCHAR(n)`	`VARCHAR(n) CHARACTER SET utf8mb4`	注意索引长度限制
`DATETIME`	`DATETIME(3)`	保留毫秒精度
`UNIQUEIDENTIFIER`	`VARCHAR(36)`	或使用`UUID()`生成
`BIT`	`TINYINT(1)`	注意驱动返回类型差异
`MONEY`	`DECIMAL(19,4)`	避免浮点精度问题
`IMAGE`/`TEXT`	`LONGBLOB`/`LONGTEXT`	大字段单独评估
`ROWVERSION`/`TIMESTAMP`	删除或改为`BIGINT`	业务不要依赖该字段
`XML`	`JSON`/`LONGTEXT`	应用侧解析逻辑需调整

函数层面，GETDATE()换成NOW()，ISNULL()换成IFNULL()，CHARINDEX()换成INSTR()，LEN()换成CHAR_LENGTH()，TOP n换成LIMIT n。这些看着简单，但一个存储过程里可能混着十来个函数，漏改一个就报错。我们的做法是先靠自动化脚本批量扫描关键字，再人工逐个 review。

2.3 自增列迁移：ID 断档与冲突的隐患

SQL Server 的IDENTITY自增列和 MySQL 的AUTO_INCREMENT看着相似，实际切换时有一个特别容易被忽略的坑：如果目标表的自增起始值没有设置成“原表当前最大值 + 1”，一旦应用写入新数据，就会出现主键冲突。我们当时的做法是：在导出数据后记录每张表的当前自增值，导入完成后用ALTER TABLE ... AUTO_INCREMENT = n手工调整。

另外还要注意 SQL Server 允许IDENTITY_INSERT ON后显式插入自增列，但 OceanBase MySQL 模式对显式插入自增列的限制更严格，需要先在会话里设置对应的 SQL mode。所有批量插入脚本都要考虑到这个差异，否则同步中断后重放日志时会卡住。

3. 搬迁执行：影子库、全量导出与增量同步的配合

3.1 影子库试跑：先让应用在新库上“跑一遍”

正式迁移之前，我们花了两周时间搭建了一个影子环境：从生产 SQL Server 备份中恢复出一套完整的库，然后把对象转换脚本跑一遍，导入到 OceanBase 测试租户。这个环境的核心价值在于让新代码提前接受真实流量的检验，而不是等割接那天才第一次见面。

影子库试跑阶段，我们把应用的所有模块都指到新库上，让 QA 团队按原有用例回归一遍。结果发现了很多兼容性 bug：有些旧存储过程在 SQL Server 里能跑，但到了 MySQL 模式下会报“Unknown column”“syntax error”之类的错误；还有些应用代码里写了 SQL Server 特有的分页写法OFFSET ... FETCH NEXT，虽然驱动是 JDBC，但 SQL 方言还残留着，必须改成LIMIT。影子库阶段发现的 bug 越多，割接那天的风险就越小，这句话在项目结束后体会特别深。

3.2 全量数据迁移：bcp 导出与 obloader 导入组合

全量迁移阶段，我们的总体方案是：

使用 SQL Server 自带的bcp工具，把关键大表导出为 CSV 文件。
通过obloader将 CSV 批量导入 OceanBase。
小表直接用应用侧脚本或 DTS 工具同步，不走文件导出。

bcp导出的时候有几个注意点。第一是要统一字符集，我们用了-C 65001指定 UTF-8 编码，避免导出后中文和马来文乱码。第二是字段分隔符要选一个数据里几乎不会出现的字符，比如\t或者|||，否则某行数据里正好包含逗号时，导入端解析会错位。第三是导出大表时要分批做，比如按主键范围分片，每片 500 万行，避免bcp长时间运行占用源库太多资源。

导入端我们前后对比过两种方式：直接使用INSERT INTO ... VALUES批量写入，以及使用obloader并行导入。实测下来obloader明显更高效，它对 OceanBase 内部做了并行分片和写入优化，2.8 亿行的最大表，按 20 个并发文件导入，大概 4 小时左右跑完。如果自己写脚本一条条插入，估计要几十个小时。

3.3 增量同步：开启 CDC 并自研消费端

全量导入完成后，业务库还在持续产生新数据，这时候就需要增量同步把源库和目标库的差距补上。我们评估过官方的迁移服务对 SQL Server 源端的支持力度，发现还不是特别成熟，索性用了 SQL Server 自带的 CDC（Change Data Capture）机制：对需要同步的表开启 CDC，然后自研了一个增量消费程序，读取变更日志，经过类型映射和函数替换后写入 OceanBase。

CDC 的开启方式不复杂，核心命令大致是：

EXEC sys.sp_cdc_enable_db; EXEC sys.sp_cdc_enable_table @source_schema = 'dbo', @source_name = 'recharge_order', @role_name = NULL, @supports_net_changes = 0;

消费端程序我们用的是 Java 写的，每秒钟轮询一次 CDC 表，获取__$operation字段判断操作类型（1=删除，2=插入，3=更新前镜像，4=更新后镜像），然后翻译成对应的 SQL 语句写入 OceanBase。更新操作在 CDC 里默认产生两条记录，需要合并成一条UPSERT，我们直接用了 OceanBase 的INSERT ... ON DUPLICATE KEY UPDATE语法，省掉了先查后写的往返开销。

增量同步期间最重要的监控指标是延迟。我们给消费程序加了 Prometheus 监控，每次同步一批数据就记录当前水位时间，如果延迟超过 30 秒就告警。整个双跑阶段持续了大概三周，增量延迟基本稳定在 5 秒以内，没有出现过丢失数据的情况。

3.4 数据校验：行数、抽样与 checksum 三重验证

增量同步稳定运行之后，还要回答一个灵魂拷问：两边的数据到底一不一样？我们做了三层校验：

第一层是行数校验：按表对比源端和目标端的COUNT(*)，每天跑一次，不等就报警。
第二层是抽样校验：对每张表随机抽取几百行，逐字段比对值是否一致，重点看DATETIME、DECIMAL、NVARCHAR这几个容易出问题的类型。
第三层是自定义 checksum：对关键大表，按主键分片，把每片所有字段拼起来算 MD5，再对比两端结果。MD5 一致基本可以认为数据完全对齐。

校验脚本本身不复杂，难的是跑批时的资源控制。千万级以上的表做全字段 MD5 很吃 CPU，我们特意把校验任务安排在凌晨业务低峰期执行，并且限了并发数，避免影响生产。

4. 迁移路上的高发坑点：兼容语法、事务隔离与字符集

4.1 T-SQL 存储过程迁移的真实工作量

存储过程迁移是这次项目里工作量最大的部分，也是坑最多的部分。有些存储过程长达几百行，里面既有动态 SQL，又用了临时表、游标、递归 CTE，改起来相当头疼。汇总一下我们遇到的高频问题。

首先是WITH (NOLOCK)全部要去掉。SQL Server 的NOLOCK提示用于避免行锁阻塞，但在 OceanBase MySQL 模式下没有这个语法。去掉之后要注意业务能否接受读已提交下的轻微锁等待，我们这里通过把隔离级别调整为READ COMMITTED，基本没有感受到明显性能回退。

其次是临时表的差异。SQL Server 的#temp表在 MySQL 模式下没有对应概念，我们统一改成了普通表 + 事务处理，或者尽量用子查询 / CTE 替代。如果确实需要临时表，记得在会话或事务结束后显式清理，否则连接池复用连接时可能出现表已存在的报错。

再就是动态 SQL 的拼接。SQL Server 的EXEC('SELECT ...')在 MySQL 模式下可以使用PREPARE/EXECUTE/DEALLOCATE，但参数占位符从@p1要改成?。如果代码里拼接了大量字符串，这一步非常容易出问题。我们的处理方式是优先改造为预编译语句，实在不行才用动态 SQL，并且做好白名单校验，防止注入风险。

4.2 事务隔离级别与死锁行为差异

SQL Server 默认隔离级别是READ COMMITTED，OceanBase MySQL 模式默认是REPEATABLE READ。如果不显式调整，某些长事务的锁范围和可见性会和我们预想的不一致，进而影响并发表现。

我们当时把所有租户级和会话级的默认隔离级别都调成了READ COMMITTED：

SET GLOBAL transaction_isolation = 'READ-COMMITTED';

还要留意的是死锁行为差异。SQL Server 的死锁检测机制比较“温和”，会选一个代价较小的会话回滚，让另一个继续执行；OceanBase 在极端并发下也有一套死锁检测，但具体表现会受事务执行计划影响。我们遇到过几次因事务里更新顺序不一致导致的死锁，解决办法很老套却很有效——所有涉及多表更新的代码，统一按照表名排序后依次加锁，避免交叉持锁。

4.3 字符集与排序规则：NVARCHAR 的隐藏成本

SQL Server 的NVARCHAR默认按 UTF-16 存储，Java 后端读取后显示一切正常。但迁到 OceanBase 后，我们统一使用utf8mb4字符集，这里有一个非常容易被坑的点：utf8mb4下一个中文字符占 4 字节，一个普通的VARCHAR(255)在大多数索引场景下可能超过 InnoDB 的索引长度限制（3072 字节）。

当时有几张表的nickname字段定义为NVARCHAR(255)，在 SQL Server 里建索引没问题，迁移后在 OceanBase 里直接报“Specified key was too long; max key length is 3072 bytes”。我们的处理方案是把这类字段统一改成VARCHAR(191)，或者使用前缀索引nickname(64)。这带来一个业务影响：如果玩家昵称很长，排序或匹配的精度可能下降，但实际游戏场景里几乎没有超过 191 个字符的昵称，测试验证后完全可用。

另外排序规则也要考虑。原先 SQL Server 里用的是Chinese_PRC_CI_AS，OceanBase 的 MySQL 模式默认可能是utf8mb4_general_ci或utf8mb4_0900_ai_ci，两者对大小写和重音字符的处理有差异。如果业务里有对字符串排序敏感的功能，比如按昵称排序的排行榜，要提前确认排序结果是否符合预期。

4.4 数据库账号与权限模型变化

SQL Server 的登录名、用户名、角色体系，和 OceanBase MySQL 模式的账号体系差异很大。SQL Server 里一个登录名可以映射到多个库，而 OceanBase 的账号通常是“用户名@租户名”的形式，权限按数据库对象去授予。迁移过程中我们给应用单独创建了专用账号，只授予SELECT、INSERT、UPDATE、DELETE和必要的EXECUTE权限，不授予 DDL 权限，减少误操作风险。

还有一个小细节是连接串。SQL Server 的 JDBC 连接串长这样：

jdbc:sqlserver://1.2.3.4:1433;DatabaseName=mydb

切到 OceanBase 后我们通过 OBProxy 连接，端口是 2883，连接串变成 MySQL 格式：

jdbc:mysql://10.0.0.10:2883/myob?useUnicode=true&characterEncoding=utf8mb4&useSSL=false

驱动从com.microsoft.sqlserver.jdbc.SQLServerDriver换成com.mysql.cj.jdbc.Driver，这行改动看似简单，但应用里如果有依赖“SQL Server 专属连接属性”的地方，需要逐个排查。

5. 割接那晚：停服窗口、连接串切换与回滚预案

5.1 切换前检查清单

割接前一周，我们列了一张很细的检查清单，这里挑几条关键的分享：

所有对象迁移完成，且跑完三轮数据校验，源库和目标库行数一致。
增量同步延迟最低降到 0，并持续观察 15 分钟以上。
应用所有连接串、配置文件、环境变量中不再包含旧库地址。
运维监控面板新增了 OceanBase 相关指标，包括租户 CPU、内存、活跃会话数、慢 SQL 数量。
数据库账号权限验证完毕，应用账号能从测试环境正常连接到目标租户并执行全部核心 SQL。
回滚方案确认，旧库保留只读访问，网络策略不变，保证可以随时切回。

5.2 应用侧只改一个配置

由于迁移过程中我们已经把 SQL 方言都改成了 MySQL 兼容写法，并且通过影子库做了充分验证，真正割接那晚的应用改动其实很小：运维把配置中心里的数据源连接串统一替换掉，然后滚动重启应用实例。

我们的停服窗口选在凌晨 4 点到 6 点，吉隆坡和北京没有时差，配合起来还比较顺畅。当天晚上的步骤大致是：

停掉应用写入流量，前端置维护页。
等待增量同步延迟归零。
停掉 CDC 消费程序，记录最终水位点。
再跑一次全库行数校验，确认零差异。
切换连接串，重启应用。
验证核心接口：登录、充值、排行榜、礼包码，按预跑脚本逐项检查。
确认无异常后，放量 10% 用户进入，观察 20 分钟，再全量放开。

整个过程比预想顺利，唯一的小插曲是切换后有几台应用节点的数据库连接池没有及时释放旧连接，导致启动时报了几条连接超时。解决办法是让运维把连接池的testOnBorrow打开，强制校验连接可用性，旧的坏连接自动剔除。

5.3 回滚预案：宁可备而不用，不可用而不备

虽然大家都希望一次成功，但回滚预案必须提前写好。我们的回滚触发条件是：切换后核心业务接口错误率超过 1%，或数据库活跃会话数持续超过预期阈值，或玩家充值链路出现数据不一致。

回滚的操作其实很简单：把配置中心的连接串改回 SQL Server 地址，重启应用。因为迁移期间源库一直还在正常接收写入，旧库数据并没有断档。唯一的损失是切换窗口内产生的少量新数据，这部分我们通过 CDC 消费端把 OceanBase 上的增量反向灌回 SQL Server，可以追平。当然，OceanBase 到 SQL Server 的反向同步没有现成工具，我们是用针对业务表的ON DUPLICATE KEY UPDATE叠加业务主键去重实现的，形式上有点粗糙，但胜在可控。

最终我们没有触发回滚，但把这个方案完整演练过两次。每一次演练都会发现新的问题，比如连接池参数不合适、反向同步脚本时间戳格式不兼容等，通通在正式割接前修掉了。

5.4 上线后的持续观察与调优

割接并不意味着项目结束。上线后的头两周，我们保持每天两次数据对账，同时关注 OceanBase 的执行计划。有一个比较明显的优化点：原先在 SQL Server 上习惯用IN (SELECT ...)的写法，在 OceanBase 上某些场景会生成低效的执行计划，需要改成JOIN或者加/*+ PARALLEL */提示。

我们还把之前 SQL Server 里一批手工维护的索引统计更新作业，换成了 OceanBase 的自动统计信息收集，省掉了 DBA 不少重复劳动。至于性能数据，最明显的变化是排行榜查询的响应时间从原来的 500 毫秒以上降到了 100 毫秒以内，晚高峰充值流水写入的锁等待基本消失，数据库 CPU 峰值也低了不少。

如果让我重新做一次这个迁移，大概率会把节奏放得更稳一点。不是说技术方案需要大改，而是团队对新数据库的“手感”需要时间培养——SQL Server 和 OceanBase 的运维习惯、错误日志解读、慢 SQL 分析思路，看着相似，实际差别不小。上线后一个月内，我们花了大量时间给开发和运维同学做内部培训，把迁移期间踩过的坑整理成文档，后续再有新项目迁过来，照着这套流程走就快多了。

另外想提醒一句：数据库迁移项目的成功不是“切完那一刻”决定的，而是从现在到你未来半年每一次发版、每一次数据修复、每一次业务变更中体现的。给团队留下足够的缓冲期，比任何技术方案都重要。