★ FEATURED ARTICLE 周一上午十点运营群里弹出一条消息排行榜接口又超时了。监控大屏上SQL Server 主库的 CPU 已经连续两个小时在 95% 以上徘徊。这不是今年第一次了。作为这家马来西亚游戏公司的数据库负责人我盯着这条消息想了很久如果继续靠增加实例规格、优化慢查询来硬扛下个月的双月活动大概率还是会出问题。会议之后我们定下来一个方向把核心业务数据库从 SQL Server 迁移到 OceanBase。整个过程从评估到切换前后花了将近三个月。中间踩过不少坑也沉淀了一套相对完整的迁移流程。这篇文章把这段经历拆开来讲包括为什么选 OceanBase、迁移前做了哪些评估、OMS 迁移链路的实操细节、兼容性改造里最容易翻车的地方以及切换当天的完整流程。如果你所在团队也正面临 SQL Server 单库瓶颈、许可证费用上涨或者扩展性不足的问题这篇文章应该能给你一些可落地的参考。先说结论这次迁移不是简单“把表结构和数据搬过去”而是把开发团队对数据库的认知整体重构了一遍。越是复杂业务越要提前把兼容性差异、改造工作量、切换和回滚方案想清楚。1. 为什么一家游戏公司要动核心数据库1.1 集中式架构扛不住增长后的真实压力我们公司的业务是面向马来西亚本地及东南亚市场的在线游戏玩法包含公会战、跨服排行榜、实时聊天和虚拟道具商城。这种业务有一个很典型的特点日常流量平稳但一开活动峰值立刻暴涨而且读写比例可以瞬间冲到 10:1 以上。活动期间的排行榜接口每秒请求量能比平时高出 30 倍几乎每个请求都要查玩家积分、排名和奖励状态。SQL Server 在这种场景下其实做了很多工作但问题是它的扩展模式太受限。集中式架构下你解决性能问题只有两条路往上堆硬件或者做读写分离。前者在云环境里意味着不断支付更高规格的实例费用后者则需要应用层接受“读从库可能有延迟”的现实。我们用过几台只读副本扛活动流量效果是暂时的但每逢大活动从库延迟还是会飘红主库的 CPU 也会跟着冲高。雪上加霜的是许可证成本。SQL Server 企业版按核心数授权生产环境只要物理核或 vCPU 数量上去费用几乎线性增长。对一家快速扩张的游戏公司来说这是很大的一笔固定开销。我们算过一笔账按当时的核心数和使用年限估算License 支出已经占到数据库总成本的 50% 以上而且每年还在继续付。这种模式对流量增长极不友好你可以接受一次性的性能扩容但很难接受“容量涨一倍、授权费也涨一倍”。1.2 我们评估过的替代方案和最终选型逻辑既然要动先看有哪些路可走。我们当时认真评估过三个方向继续用 SQL Server 并做垂直拆分、换到开源 MySQL 自建分库分表、迁移到 OceanBase。垂直拆分是最容易想到的方案。比如把会员、商城、日志拆到不同实例再引入中间件做一些路由。这个方案的问题是游戏业务的数据关联太强一个玩家在充值、邮件、排行榜、成就系统里的记录经常要跨模块查询。拆完库之后要么大量接口做应用层聚合要么引入分布式事务。我们评估后认为拆库带来的应用改造量可能比换数据库还要大。自建 MySQL 加中间件也类似虽然省了 License 费用但分片键设计、全局唯一 ID、跨分片查询这些问题都要自己和业务方一点一点解决团队成本太高。最后我们把目光放在了 OceanBase 上。它一开始吸引我们的点很简单对外表现像一个集中式数据库开发人员不用关心分库分表但底层是分布式架构可以通过加节点做水平扩展。对一家以游戏业务为主、DBA 团队并不庞大的公司来说这种“扩展性交给数据库”的模式是最舒服的。更重要的是OceanBase 的数据存储采用基于 LSM-Tree 的架构压缩比在游戏日志这类数据上非常可观意味着存储成本也能压下来。选型不是拍脑袋我们当时做了两周的 PoC。用它跑过排行榜 Top N 的典型查询、高并发写日志的压测还模拟过节点宕机后的自动恢复。结论是OceanBase 在读写混合场景下的吞吐能力明显优于当时的 SQL Server 单机配置而且不需要应用层做分片逻辑。这一步走完后管理层很快就拍板了。2. 迁移前必须想清楚的兼容性差异2.1 先盘点存量资产再谈迁移很多团队会犯一个错误拿到迁移任务后直接开同步工具结果数据导到一半发现表结构不兼容、存储过程编译不过、应用连上来一堆报错。实际上真正有价值的迁移时间应该花在“前期评估”上而不是“后期救火”。我们第一步是全网盘点数据库资产。用脚本定时收集实例信息最终产出一张完整清单实例数量、库名、表数量、单表行数、TOP 大表的容量、慢查询分布、索引数量、存储过程和触发器数量以及数据库 Job 调度情况。只有把这张清单拉出来你才能知道改造范围有多大哪些对象是核心哪些可以直接丢弃。盘点完成后我们对业务做了分级。核心交易类数据包括充值流水、订单记录、虚拟道具发放等必须保证强一致性和零丢失玩法类数据如玩家等级、经验、任务状态对一致性要求也较高日志类数据包括战斗记录、客户端埋点、行为追踪量大但容忍一定延迟。针对不同级别的数据迁移策略完全不一样核心数据全程走 OMS 的全量加增量日志类数据则可以分批导出、适当压缩、允许短窗口追平。这里贴一个我们当时的资产盘点简表方便你理解这个阶段的产出物长什么样对象类型数量兼容性风险备注业务数据库12中部分老库存在废弃表和冗余索引数据表680中单表超 1 亿行的有 15 张存储过程320高T-SQL 语法改动量最大触发器45高部分触发器依赖即时执行语义SQL Server Job30中改用 OceanBase 调度器或外部队列2.2 T-SQL 方言与 OceanBase SQL 的关键差异这一节是整篇文章里最需要耐心看的部分因为兼容性差异决定了改造工作量也决定上线后会不会半夜被报警电话叫醒。第一数据类型映射。SQL Server 和 OceanBase 的 SQL 语法虽然都属于关系型数据库体系但类型系统差异明显。我们用到的几个主要映射如下nvarchar/varchar统一按varchar或varchar2类字符类型处理注意确认多字节字符集的存储空间。datetime/datetime2映射为 OceanBase 的datetime/timestamp但精度要提前看。datetime2(3)在 SQL Server 里毫秒截断规则和 OceanBase 不完全一致容易造成数据校验对不上。uniqueidentifier在 SQL Server 里是原生 GUID 类型OceanBase 里需要迁移为char(36)或varchar(36)对索引构建方式和查询性能会有影响。ntext/image这类老式大字段类型建议统一转成longtext/blob类但要注意转换后字符集和长度的变化。decimal/numeric映射到 OceanBase 的decimal主要确认精度和标度定义一致。第二排序规则与大小写敏感。SQL Server 的默认排序规则通常是Latin1_General_CI_AS也就是不区分大小写OceanBase 的默认字符集是utf8mb4在比较时默认行为不一样。如果原来的唯一索引依赖大小写不敏感迁移到 OceanBase 后很可能遇到唯一键冲突。我们的办法是在数据库级别显式指定排序规则并根据业务场景对字段做了逐一确认。第三分页语法。这是迁移中看似简单其实很容易漏掉的一个点。SQL Server 常用的OFFSET FETCH和ROW_NUMBER()窗口函数分页在 OceanBase 里并不能全部等价替换。标准做法是把OFFSET FETCH改写为LIMIT offset, count把ROW_NUMBER()逻辑改成 OceanBase 支持的窗口函数写法。如果应用代码里大量使用 ORM你还需要在 ORM 层配置或重写来避免低效的全表扫分页。第四自增列和序列。SQL Server 的IDENTITY列和SEQUENCE对象在 OceanBase 中需要换成AUTO_INCREMENT或SEQUENCE的等价实现。这里有一个容易忽略的细节SQL Server 的 identity 值通常每张表独立维护而 OceanBase 的AUTO_INCREMENT与内部序列实现有关系迁移时如果保留原始值必须显式插入并更新序列的下一个值否则后续新插入的数据可能主键冲突。第五系统函数。我们项目里用到的函数比较多比如GETDATE()要改成NOW()或SYSDATE()SCOPE_IDENTITY()要改成通过LAST_INSERT_ID()获取ISNULL()改成IFNULL()。这类改动本身不难但数量多、藏在存储过程和业务代码里容易漏网。建议用脚本做一次全量扫描把所有 T-SQL 特有函数出现的地方都列出来再逐条确认。第六多表更新和删除。SQL Server 支持UPDATE A SET A.col ... FROM B WHERE ...的写法OceanBase 也支持类似语法但细节有差异。我们在真实改造中遇到几个更新因为别名先后顺序不同导致执行计划变更所以要仔细核对 WHERE 条件中的列引用确保语义一致。2.3 应用代码的改动面与工作量估算数据库兼容性评估只是第一步更关键的是搞清楚应用层要改多少。我们公司的后端主要使用一套自研的 Java 网关加 C 游戏逻辑服务数据访问层比较重直接拼 SQL 和调用存储过程的比例不低。这意味着兼容性改造不能只靠“数据同步工具自动完成”还需要开发团队重新编译、回归测试。我们采用了一个“分层估算”的方法。第一层是连接方式和驱动检查 JDBC 连接串、连接池参数以及超时配置这一层改动量不大。第二层是 DAO 层和 ORM 映射逐项检查Query注解或者 XML 中的 SQL把所有 T-SQL 特有的函数、分页语法和类型映射问题标记出来。第三层是存储过程这类改动最头疼因为 T-SQL 的存储过程可能包含游标、临时表、表变量、动态 SQL 等复杂结构改写为 OceanBase 存储过程时必须重写逻辑。工作量估算建议用“代码扫描加人工确认”的方式。我们自己写了一个扫描工具先按关键词把可疑 SQL 全部揪出来然后交给各业务模块的开发负责人逐条确认。最终统计下来应用代码 SQL 改动大约 120 处存储过程改造约 90 个总工作量相当于集中投入三周。这个数字相比整个迁移周期来说并不大但如果没有前期扫描全靠运行时报错来逼着改那过程就会非常痛苦。3. 迁移链路与工具选型3.1 为什么直接用 OMS 而不是自研同步面对数据同步方案团队内部出现过两个声音。一部分人觉得我们已经有跨区域数据复制经验可以参照旧方案自己做一套另一部分人倾向用官方提供的迁移服务 OMS。现在回头看直接用 OMS 是正确的选择。自研数据同步的复杂度很容易被低估。表面上你只需要全量导一遍数据再解析 SQL Server 的事务日志做增量回放。但实际做起来会发现日志解析要处理各种 DDL/DML 顺序、大事务、DDL 锁、位点记录和断点续传。你辛辛苦苦写完一套同步程序稳定性还不一定比得上专门做这个的产品。OMS 天然支持 SQL Server 到 OceanBase 的迁移链路全量加增量、数据校验、性能监控都在一个控制台里完成省掉了我们大量造轮子的时间。使用 OMS 之前建议先确认几个前置条件源端 SQL Server 的版本要在 OMS 支持的范围内源库需要开启相应的日志记录能力供增量同步读取目标端 OceanBase 集群的版本也需要满足兼容要求。我们中间有一次因为源库实例版本太老OMS 的迁移项目创建后一直提示日志位点不连续后来升级了源库小版本才解决。3.2 增量同步与容量规划很多团队在规划迁移时重点关注应用代码改造却忽视了目标端容量规划。OceanBase 的租户设计和传统 SQL Server 实例差异很大租户内存、CPU、日志空间都是需要提前配置的。我们在迁移前做了一个容量测试。先把历史全量数据导入测试租户观察占用空间和压缩比再按活动峰值流量估算 TPS/QPS 以及对应的 CPU 和内存需求。游戏日志类数据在 OceanBase 里的压缩效果很好数据文件占用只有 SQL Server 的 40% 左右这是我们没想到的一个惊喜。但也因为 LSM-Tree 的架构特性内存中需要保留一部分热点数据和写入缓冲所以租户内存的规划不能只按照“活跃数据”估算要预留出写入吞入量和合并缓冲空间。另外迁移目标是新建业务租户还是挂在已有租户下也需要提前决定。我们最终为迁移后的核心业务单独创建了一个租户一方面方便做资源隔离另一方面也便于观察迁移后的真实负载。这种做法可以避免因为其他业务干扰导致性能问题。4. 实操实录全量导出、增量追平与校验4.1 环境准备与权限收敛迁移环境的核心原则是“最小权限”。不要图省事拿一个 sysadmin 账号给迁移工具那样安全上会留很大隐患。我们从源端新建了一个迁移专用账号只授予读取元数据和读取数据的权限具体包括实例级别的View Server State用于读取日志位点。数据库级别的VIEW DEFINITION用于读取表结构。对需要迁移的库授予SELECT权限。如果有结构迁移需求再额外授予CREATE TABLE、ALTER等 DDL 权限。目标端同样建议使用低权限租户账号仅授予迁移库的读写权限。OMS 项目创建时我们按照“结构迁移 全量迁移 增量同步 数据校验”四步配置跑起来之后就可以在控制台里看到迁移进度。4.2 全量迁移的参数细节全量迁移阶段最容易把源库压垮。我们在第一次全量测试时因为默认并发较高SQL Server 源库的 IO 直接被拉满导致玩家在线时长和埋点写入延迟飙升。这次教训让我们把全量任务的并发数调低并特意选择在业务低峰期跑。几个关键参数值得留意并发拉取线程数建议从低到高试探比如先从 4 开始观察源库 CPU 和 IO 之后再逐步增加。分批大小按主键范围分批读取时批次不要太大也不要太小。过大会放大单次查询的 IO 压力过小会导致网络往返太多。我们实践下来单批次在 500 到 2000 行之间比较合适。网络带宽如果源库和目标库不在同一机房还要考虑跨地域带宽。我们为了减少网络延迟把目标端预先把大表迁移到距离源端更近的机房迁移完成后再做跨机房同步。全量阶段还有一个小技巧大表先拆分再迁移。比如战斗日志这类按时间增长的大表我们提前在 OceanBase 侧建好分区表再把每个分区的数据分别拉取。这样不仅能控制单批数据量后续增量同步的压力也会小很多。4.3 增量同步阶段的关键指标全量数据导完之后最主要的工作是让增量链路追平源库的实时写入。OMS 控制台里可以看到同步延迟、RPS 和 TPS 等指标。我们把延迟阈值设置为 3 秒以内也就是从源库提交事务到目标库可见的时间差不能超过 3 秒。增量同步出现延迟的原因通常有几类源库日志读取权限不足导致读取阻塞大事务回放耗时过长目标端写入争用严重。我们有一次因为某个开发同事在源库跑了一个批量更新 200 万行的存储过程直接导致增量同步延迟飙升到十几分钟。这件事带来的教训是在迁移窗口内尽量不允许业务侧执行超大规模批处理如果有需要必须提前报备并进行拆分。增量阶段还有一个容易被忽略的工作持续监控数据校验结果。OMS 自带的数据校验可以按表做行数对比、抽样对比和全量对比。我们每天跑一次抽样校验每周末跑一次全量校验。校验过程中发现的差异大多数情况下不是同步链路问题而是源端数据本身在并发写入时被读取到了不一致快照。这时候只要在同步任务里重新触发增量即可。4.4 数据校验除了数行数还能做什么谈到校验很多人第一反应是“数一下两边行数是否相等”。但行数相等只能说明数据“量”对上了不能说明“内容”对上了。我们当时在行数校验基础上叠加了三层验证聚合对账对金额、积分等数值字段做 SUM 对比。这个方法简单有效能发现大部分重复或缺失的数据。抽样全字段对比按照主键采样 5% 的数据逐字段做二进制对比。发现不一致时再逐步扩大采样范围。业务规则对账比如订单状态流转必须保证目标库中的记录和源库完全一致因为后端服务会依赖状态字段做幂等判断。校验脚本建议写成自动化任务而不要靠人工点按钮。我们自己写了一个 Python 脚本每天凌晨拉取 OMS 的校验结果推送到内部监控平台。一旦对账异常告警会直接发到值班群这样即使有偶发不一致也能快速定位。5. 兼容性改造中最容易踩的坑5.1 数据类型转换中的精度陷阱这一节讲的都是我们当初真正踩过的坑如果你正在做类似的迁移可以拿这些点去逐个排查。第一个坑是时间精度。SQL Server 的datetime精确到毫秒datetime2可以精确到微秒而 OceanBase 的timestamp精度需要在建表时明确指定。我们有一张玩家充值记录表原来用datetime2(3)建表语句迁移后默认变为了timestamp(6)。看起来精度更高了但实际上业务代码中读取到的字符串格式变化导致后台导出报表时出现了时间偏移。后来统一收敛为timestamp(3)同时调整了所有相关接口的时间格式化逻辑。第二个坑是 GUID 字段的存储方式。uniqueidentifier改为char(36)后如果直接在 GUID 列上建索引字符序和二进制序不同查询性能会下降。我们最后把部分 GUID 列改为有序字符串存储或者在应用层用雪花算法生成的分布式 ID 替代避免不必要的性能损耗。第三个坑是nvarchar(max)被映射为longtext。SQL Server 中nvarchar(max)常用于大数据量文本存储OceanBase 的longtext也能存大字段但索引策略不一样。凡是需要 WHERE 条件过滤的长文本字段都不适合直接在大字段类型上建索引。如果业务有这种查询必须提前加冗余列或者改为前缀索引。5.2 事务行为差异引发的死锁与超时数据库迁移之后最怕的是并发行为变化导致线上出现死锁。SQL Server 的锁定和阻塞机制与 OceanBase 的 MVCC 机制存在肉眼可见的差异。SQL Server 默认使用悲观锁写事务在提交前持有锁读事务在快照隔离级别下不会阻塞写。OceanBase 的实现更接近于多版本并发控制读请求通过快照读不加锁写事务之间才需要判断冲突。这种差异带来的直接影响是相同的一句 UPDATE 语句在两种数据库里可能产生完全不同的锁等待链。我们迁移后第一周就碰到过一次死锁高发。排查后发现原因是一条更新排行榜积分的 SQL在 SQL Server 里通过WITH (UPDLOCK)强制加锁来避免并发覆盖但这个写法在 OceanBase 里语义并不完全一样反而扩大了锁范围导致更多锁等待。解决办法是去掉多余的锁提示改为依赖 OceanBase 自己的事务冲突重试机制。另一个需要注意的地方是事务超时时间。SQL Server 的LOCK_TIMEOUT默认是 -1也就是无限等待OceanBase 里的事务超时则受租户级参数控制例如默认的ob_trx_timeout为 100 秒。长事务如果超过这个时间会被系统自动回滚应用层如果没有做重试补偿就会直接报错。我们在迁移后把所有核心服务的数据库操作时长监控都加了告警确保没有长事务悄悄触顶。5.3 存储过程改写中的难啃骨头存储过程是这次迁移中改造量最大、也是最容易出现隐蔽 Bug 的部分。T-SQL 存储过程有一些特有语法和编程习惯迁移到 OceanBase 后必须逐条处理。先说表变量和临时表。SQL Server 中DECLARE table TABLE (...)这种表变量在 OceanBase 中没有等价物。我们统一把表变量改写为临时表但要注意会话级临时表生命周期和事务的关系。如果存储过程里有多处递归调用或者动态 SQL临时表的作用域规则也可能导致数据错乱。再说游标。T-SQL 里的游标虽然性能不算好但写法简单很多老存储过程直接循环逐行处理。OceanBase 也支持游标但我们在实际改造中发现嵌套游标容易触发内部错误后来把大部分游标改写为基于临时表加集合操作的逻辑整体性能反而提升了不少。最后是动态 SQL。SQL Server 中频繁使用EXEC(SELECT ... WHERE column value)动态拼 SQL迁移后虽然 OceanBase 支持 PREPARE 方式但动态 SQL 必须严格防止注入而且执行计划缓存效果完全取决于绑定变量使用的好坏。我们改造时把所有动态 SQL 都重写为参数化查询不直接拼接字符串。这一步虽然工作量大但对上线后的稳定性至关重要。5.4 切换前最容易忽视的字符集问题字符集问题平时不显眼一旦触发就是系统级问题。我们的玩家昵称是典型的多语言场景马来文、中文、英文都可能有甚至会有人往昵称里塞 emoji 表情。SQL Server 使用nvarchar类型时对 Unicode 支持还可以但迁移到 OceanBase 后如果字符集设置不对轻则排序错乱重则直接写不进去。我们的处理方式是所有表结构迁移前统一检查字符集定义目标库使用utf8mb4并在数据库层把排序规则显式设置好。对于一些关键的唯一索引列比如玩家账号、设备号还要额外确认大小写敏感性。我们上线前的最后一个晚上就是因为两张表的排序规则不一致导致唯一索引校验失败差一点延误切流。这里的教训是字符集和排序规则必须在全量迁移前就定死不要等到数据同步完再改。6. 切换当天的完整流程与回滚预案6.1 灰度切换设计数据迁移完成不等于上线完成。我们做了一次典型的灰度切换把流量分批次切到 OceanBase而不是一次性把所有请求导过去。第一阶段切只读流量。把排行榜查询、玩家信息读取、运营报表这类读多写少的请求先指向 OceanBase。这一阶段如果出现问题影响面可控回滚也简单只需把网关的路由规则改回去。第二阶段切写流量中非核心的部分比如埋点日志、行为追踪等异步写入。第三阶段才切核心写流量包括充值、订单、虚拟道具交易等。每个阶段安排两到三天的观察期。观察期内重点看接口 P99 延迟、错误率、死锁数量以及 OMS 同步延迟。灰度切流的好处是一旦发现某个模块在 OceanBase 上有性能回退可以立即把流量再切回去不需要牵扯整个系统。6.2 切换当天的Checklist正式切换我们选择在一个凌晨的维护窗口执行尽量减少对玩家的影响。整个流程可以归纳成下面这张时间表时间点操作验证内容00:00停写所有业务发布维护公告确认入口流量降为 000:10停止 SQL Server 端定时任务和批处理确认源库无新增写入00:20等待 OMS 增量同步延迟追平为 0查看同步延迟指标00:30执行最后一次全量数据校验行数、聚合、抽样全部一致00:45切换数据库连接串指向 OceanBase 租户登录和健康检查通过01:00逐步放量从 10% 到 50%监控错误率和延迟01:30放量到 100%观察核心接口稳定性02:00开启写流量交易链路回归通过02:30恢复业务运行停止维护公告全员监控值班切换当天最大的要求是“不要临时创新”。所有脚本和命令都提前准备好DBA、后端负责人、测试同学各就各位按清单严格执行。我们都曾有过“顺手再改一下参数”的想法但每次都提醒自己切换窗口内任何未经验证的改动都是给事故留机会。有一点值得单独强调切换前一定要做回滚演练。我们光“切到 OceanBase 再切回 SQL Server”的演练就做了三轮包括应用重启、连接串回切、增量链路恢复、数据追平。真正回滚时唯一要保证的是源库始终处于完好状态。我们是保留 SQL Server 源库至切换后一周期间每日做一次数据快照确认新库稳定后才正式下线。6.3 回滚方案的底线与可操作性回滚方案的第一原则是“可操作而不只是存在”。很多团队的计划里写着“如果出现问题回滚到旧数据库”但不定义触发条件、执行步骤、时间窗口这样就等于没有回滚方案。我们定义了三种回滚级别。第一级是回切只读流量如果只读接口出现大面积超时直接把网关只读流量指回 SQL Server。第二级是回切全部流量这种情况适用于核心写链路崩坏或数据写入异常需要在停服状态下切换预计耗时 30 分钟。第三级是数据回灌如果上线后发现 OceanBase 侧有数据丢失或逻辑错误就需要从源库和备份中恢复同步链路这个方案耗时较长尽量只在极端情况使用。切换后一周内每天我们都会回答三个问题新库的慢查询数量是否在下降有没有出现事务超时告警OMS 增量链路是否还正常回答不了任何一个就说明回滚的警铃应该被敲响。7. 上线后的稳定期观察与成本收益复盘7.1 从“救火”到正常的监控体系上线稳定期监控体系的调整很关键。之前围绕 SQL Server 的监控模板很多不需要了需要逐步建立起 OceanBase 的监控视图包括租户 CPU、内存、存储水位、合并进度、慢查询数量、活跃会话数等指标。我们保留了一个和 SQL Server 时代相同的对比报表每天早上拉取核心接口的 P99 延迟和数据库慢查询 TOP 20。迁移后的结果总体是积极的排行榜接口的 P99 延迟从之前的 850ms 下降到 240ms充值流水写入的吞吐提升了近一倍。最明显的变化是活动高峰期数据库 CPU 不再有持续打满的现象而是可以随着 OceanBase 节点扩容平滑分摊。另一个值得关注的细节是慢查询。SQL Server 的查询计划优化器主要针对行存储OceanBase 的优化器对分区裁剪、并行查询和索引选择有自己的逻辑。同样的 SQL在两边执行计划可能完全不同。我们上线后前两周安排了专职 DBA 逐个分析慢查询并把其中一些优化过度的 SQL 重新改写。这里记住一个原则不要迷信“原 SQL 在 SQL Server 上很快所以在 OceanBase 上也快”执行计划必须重新看。7.2 成本收益算笔账从成本角度讲这次的迁移收益是非常可观的。License 费用直接降为零数据库硬件方面我们将原来的 8 台高配物理机缩减为 5 台 OceanBase 节点同时由于集群压缩比更好存储硬件采购压力也明显减轻。综合下来数据库基础设施的年度总成本下降约 30%。运维层面的收益同样不可忽略。SQL Server 时代每逢大活动DBA 都要提前扩容、压测、盯从库延迟现在 OceanBase 的多副本高可用和自动故障切换机制大大减轻了“半夜手工切库”的压力。原来每天需要花 2 小时处理的数据库维护工作现在几乎可以自动完成。但要注意成本下降是建立在合理容量规划之上的。OceanBase 的内存资源比较宝贵如果租户内存设置过小会出现写入性能下降甚至合并超时。所以上线后每个月都观察一次租户内存和存储水位及时调整资源规格不要等告警了再处理。7.3 给准备迁移的团队几个建议最后以个人的视角给准备做类似迁移的团队提几个建议。第一把兼容性差异清单当成产品文档来维护。不要只在 DBA 内部传阅要让所有涉及 SQL 的研发同学都看过。很多时候线上出问题不是因为某个人不会改而是因为没有人提前告诉他这里有差异。第二不要在迁移窗口内设计新功能。我们当时有一个外部系统提出要在切换当晚同时上线新模块被我们坚决否掉。数据库切换和业务发布应该严格分开任何叠加变更都会让问题排查变得极其困难。第三重视演练。切换演练不是走流程是真的要把流量切过去再切回来让团队所有人熟练整个操作流程。演练时暴露出的脚本权限问题、监控遗漏问题都要当成真正的生产事故对待。第四给数据校验留足时间。全量迁移完不等于数据没问题校验要贯穿整个增量同步阶段。最好把校验做成自动化流水线每天产出校验报告这样才能在正式切换前发现所有数据一致性问题。这次从 SQL Server 到 OceanBase 的迁移给我们带来的不仅是数据库性能和成本的改善更让整个团队重新审视了一遍所有核心业务的数据流和事务边界。数据库迁移从来不是一个 DBA 或一个基础设施团队能单独完成的事它需要研发、测试、运维共同把旧系统里每一个隐晦的假设晾到阳光下。而在经历过一遍之后你再看任何系统改造项目都会多一分准备少一分侥幸。
阅读完成 · 觉得有帮助？
)
