携程从MySQL搬到OceanBase中那些踩过的坑和学到的经验分享

主要参考了携程技术团队在2018年左右公开发布的几篇技术博客,特别是题为《携程MySQL迁移OceanBase实践》和《OceanBase在携程的落地与挑战》的文章，以下是他们分享的核心内容：

携程最开始考虑用OceanBase替换MySQL,主要是因为业务增长太快，一些核心的MySQL数据库已经快撑不住了，比如订单、支付这些系统，经常面临性能瓶颈和存储空间不足的难题，他们希望OceanBase这种分布式数据库能解决两个大问题：一个是弹性扩容，就是需要更多资源时能像搭积木一样加机器就行；另一个是高可用，做到真正意义上的数据不丢，服务不停。

但想法很美好,真动手搬的时候，坑是一个接一个，第一个大坑就是“兼容性”问题，虽然OceanBase宣传兼容MySQL协议，但毕竟是两个不同的东西，就像都是汽车，手动挡和自动挡开起来感觉还是不一样，携程发现，他们直接把自己在MySQL上跑得好好的SQL语句扔到OceanBase上，很多就跑不动了，或者跑得特别慢，这里面有语法层面的细微差别，比如一些复杂的SQL函数或者子查询的写法，OceanBase的解释器可能不认识或者处理逻辑不同，更重要的是，两个数据库的“优化器”完全不一样，MySQL的优化器可能觉得全表扫描快，但OceanBase的优化器在分布式环境下有自己的一套判断逻辑，这就导致了很多在MySQL上是“优等生”的SQL，到了OceanBase直接变成了“差生”，严重拖慢整个系统，他们的解决办法就是花了大把时间做SQL的兼容性测试和改写，相当于给SQL语句做“翻译”和“再教育”，让它们适应OceanBase的环境。

第二个坑是“事务和锁”的差异，携程的很多业务，像订酒店扣库存，对事务的一致性要求非常高，MySQL是单机数据库，事务处理相对直接，而OceanBase是分布式的，一个事务可能涉及多台机器，它用了类似两阶段提交的复杂机制来保证数据一致性，这个机制本身很可靠，但携程在迁移过程中发现，他们原有应用代码里的一些“野路子”写法，在MySQL下可能侥幸没事，但在OceanBase严格的分布式事务模型下就暴露问题了，比如一些非正常的事务提交或回滚顺序，可能会在OceanBase上引发意想不到的锁等待，甚至死锁，他们不得不回过头来，仔细梳理和规范应用层的事务代码，确保它们符合分布式事务的最佳实践。

第三个让他们头疼的问题是“生态工具”的缺失，MySQL发展了很多年，周边工具非常丰富，比如好用的监控工具、数据备份恢复工具、数据同步工具等，而当时OceanBase作为一个较新的系统，这方面的生态还不太完善，携程发现，他们习惯用的那套MySQL运维工具链，在OceanBase上很多都用不了，怎么快速备份海量数据？出了问题怎么快速定位？他们只能和OceanBase的研发团队一起，从头开始搭建适合携程自身需求的监控告警系统、运维管理平台，这个过程相当于重新发明轮子，耗费了大量的人力和时间。

除了踩坑,他们也学到了宝贵的经验，最重要的一条经验是：分布式数据库不是单机数据库的简单替代品，迁移更像是一次“系统重构”，你不能指望像换一个灯泡一样，把应用直接插上去就能用，它要求开发者和运维人员转变思维，从“单机思维”切换到“分布式思维”，比如设计表结构时，要特别关注“分区键”的选择，这直接决定了数据怎么分布到不同机器上，对查询性能至关重要，再比如写SQL时，要有意识避免那些可能导致跨大量服务器查询的操作。

另一个关键经验是必须进行充分、再充分的测试，携程强调，不能只做功能测试，一定要做贴近真实场景的压力测试、 longevity test（长时间稳定性测试）、故障演练（比如模拟一台机器宕机看系统能否自动恢复），他们是在一个非核心业务上先做了好几个月的前期试点，把所有能想到的问题都暴露和解决得差不多了，才敢动核心的订单库。

他们认识到与应用团队的紧密协作至关重要，数据库迁移不是DBA（数据库管理员）自己能搞定的事情，因为很多改动涉及到应用代码的调整，比如SQL改写、事务逻辑优化等，必须拉着业务开发同学一起干，大家目标一致，共同承担责任，才能把事情推进下去。

携程的体会是,从MySQL迁移到OceanBase是一次挑战巨大的系统工程，成功的关键不在于技术本身多先进，而在于对细节的极致把控、充分的测试准备以及跨团队的紧密合作，这个过程虽然痛苦，但一旦成功，带来的系统可扩展性和高可用性提升也是巨大的。