今早的F1墨西哥站，以法拉利二连胜结束，秋休之后的红色跃马，一度强悍的让我不认识，从蒙扎赛道升级开始，一路在积分榜紧追，终于今早成功超越红牛来到第二。与之形成鲜明对比的是上半个赛季巴塞罗那站带来的一系列负升级。负升级是个什么概念？在赛车领域，可以近似理解为，赛车带来的升级套件非但没有提高竞争力，反而成为了性能桎梏，法拉利在过去几年每每负升级，让诸多铁佛寺心力交瘁。
然而负升级其实不仅仅存在于赛车，在数据库这个赛场，也是常见的。
负升级，左右路线颓废
我在做产品经理的时候，负升级是最为头疼的。有时候明明想法很好，然而计划永远赶不上变化，总有想象不到的点，让产品变成负升级。
在0.4版本的时候，当时的计算主开将引子化算法性能推到了一个阶段性的极致。无论是宽表SSB还是多表join，都获得了很不错的性能，以至于在那个时候，我每天孜孜不倦地去跑性能，经常一跑就是晚上11点收工乐在其中。伴随着0.4发版，整个性能也到达了一个极致。
然而到了0.6的时候，性能突然就降了，几乎是毫无心理准备的。虽然和研发测试的同事不断排查，却依旧没能找到究竟后面哪项功能或者性能的升级导致。于是乎，只好本着头疼医头的思路，继续往前走。哪里性能不理想，就优化哪里。这是我第一次体会到，负升级在数据库领域的悲催和无奈。差不多一直到我离职之前的1.0版本，这几个benchmark的性能才勉强追回来一些，在部分场景甚至超过了之前的版本，但是这个代价真的太大了。
然而，这只是数据库负升级诸多场景的一部分。后面诸如稳定性、数据一致性、事务行为，都出现过多多少少的负升级，有的甚至在我离职之前都找不到最核心的原因。
事后我和主开反思回顾，为什么会出现如此多的负升级？经过我俩毫无保留的嘴炮，最后归纳总结出几点：
1. 顶层设计。代码缺少顶层设计，每次都是各个模块各自开发各自的，到了联调阶段，很多不兼容或者互相影响的地方就都出来了。
2. 贪多嚼不烂。要开发的功能太多，主次不分，到底是剑宗还是气宗说不清。工期紧张根本无暇顾及质量，在这种情况下冰山下的问题多如沙丁鱼群（我想用牛毛，想了想冰山下好像没有）。
3. 代码质量。正是因为没有顶层设计，内容又多，因此代码质量根本无法兼顾到，大量质量不合格的代码合入之后，带来的破坏性无法估计。
正升级，跬步以之千里
4.2.5重点在TP，作为产品体验官我还有幸采访了产品经理。几个问题回答条理清晰，而且让我感觉到，主次都明确，该做什么该优化什么都清晰。结合前面从4.2.0开始到4.2.5，产品设计和规划就很明确。
1. 可观测性。可观测性的根基在于能否及时收集保存并汇总统计数据库的各项指标，这方面从4.2.1开始到4.2.5，新增SQLSTAT、LogMiner、ASH REPORT 增强、实时诊断能力增强、系统日志优化等几个特性在几个版本一年的时间里完成，肉眼可见提升了这方面。
2. 兼容性。OceanBase支持MySQL与Oracle两个不同产品的语法语义，在几个版本当中也有体现，比如Oracle兼容性方面，4.2.2新增DBLink 支持调用远端 UDF，4.2.3新增DBMS_PROFILER，4.2.4新增租户间调用存储过程，这些都是实用且在迁移中常用的功能。
3. 高可用。OceanBase的高可用既要支持Oracle的主备概念，又要在云原生分布式上多地多活，前者新增了主备租户切换验证的功能（switchover）、物理备库并行同步，后者增加了同城双机房最大可用、支持对象存储备份等功能。值得注意的是，备份恢复这里仍然有很多功能待开发，开发团队还是保持了克制来换取稳定可靠。
4. 性能。光是4.2.5和性能提升有关的就有很多项，而且很多项目并不是为了benchmark跑分而做的优化，包罗了升级性能优化、恢复性能优化、部分DML性能优化。事实上，性能优化本身就是覆盖诸多方面，不执着于benchmark而关注实际生产的综合性能，才是正道。
从4.2.0到4.2.5，差不多一年半。以OceanBase开发团队的规模和发布的内容，可能谈不上非常多，但是主线很清晰。而且经过我几天的测试，排除个人投入时间有限可能没覆盖到的因素，实际并没有发现负升级的内容。大概率，我自己踩过的三个坑，在OceanBase都没有发生过。每次升级都没有遇到负升级，就已经实现了市面上很多国产数据库没有实现的目标。
其中的优化以及新特性，我也在不断学习消化中。这一过程中，如果遇到我认为不合理的地方，也会把自己的想法观点反馈给OceanBase团队。
虽然昨晚只睡了4个小时，但是仍然被法拉利二连胜的战绩刺激的毫无睡意，于是在看完比赛之后，坐在床上写完了这篇文章。有趣的是，主场作战的佩雷兹成绩惨不忍睹，维斯塔潘连续两个罚时，也让自己的积分又被诺里斯追了10分。只是不知道，未来Oracle还会不会继续赞助红牛车队。
