分布式数据库版本迭代快，对用户来说是真的好吗？

我们的解决策略是：只做大版本升级，减少升级次数。
厂商经常会做一些打补丁、优化的操作，大部分都是小版本更新，那么除非对业务或应用影响大的情况会单独升级，否则我们会把所有小版本更新集中到一个包里，一次性做个较大版本的升级，以减少次数。

现在分布式数据库更新的版本多又快，主要还是因为问题相对比较多，解决一些已知bug，但是为了解决bug频繁进行升级和迭代，这样会带来很大的变更风险和工作量，这样带来的收益反而降低，如果不是极大影响数据库，不建议频繁升级，十次事故九次变，减少变更，等版本稳定可以统一升级到一个稳定版本。

分布式数据库上面往往放了多个业务的数据库，如果升级需要停机，那对于升级窗口很少的用户来说是个大问题。期待厂商能做到对用户无感知。

一个产品的生命周期包括初创期、建设期、稳定期、消亡期。在前两个周期存在频繁迭代是正常的，稳定期应当固定的、较长周期的迭代。

数据库是应用系统的重中之重，频繁迭代必然带来风险。我们需要反思2点：

1、从数据用户侧产品选型：是否考虑了产品发展周期？是否很好地平衡“为满足业务需求不得不采用某个产品”和“该产品频繁迭代带来的问题”？在系统变更、数据完整等方面做了哪些设计来应对风险和运维压力？

2、从产品研发侧迭代策略：当前产品所处阶段和快速迭代是否匹配？新功能、新Bugfix是否解决了用户的痛点（是否价值大）？

作为系统架构师，需要做好权衡和应对。

现在国产数据库还处于成长阶段，快速迭代是应对需求的正反馈。
以前总是抱怨国外产品不理会客户需求，现在国产数据库对需求的反馈很积极，充分说明了国产的必要性。
当然，国产数据库的版本管理比较混乱，没有清晰的产品路线图，客户需求管理不规范，需要加倍努力。

个人认为版本迭代也分情况考虑：
1、小版本迭代通常是用于修复Bug，不带入新增功能，此种类型的小版本快速迭代有助于快速修复数据库Bug与隐患。
2、大版本迭代通常是增加新功能与性能优化。此类型的版本快速迭代不适用于对稳定性要求较高的系统。而对于一些对数据库性能要求较高的系统，可在测试环境试用最新版本，验证新版本在性能上的提升程度。另外我认为大版本的迭代，应尽量减少运维体系的变化，降低运维学习成本。

从用户角度只能接受有计划的版本迭代和升级，否则面对的都是风险和麻烦！国产数据库厂商在这块做的尤为不好，看着好像厂商针对问题及时进行bug完善，对用户来说是好事，其实不然，用户是需要稳定和安全，一个版本的上线，已经经过很多人的参与，如果短时间内又要经过版本更新，对用户的运行维护来说实在不便。从用户角度来说绝对不是一件好事情。

厂商版本更新没关系，对用户来说是绝对不行随时版本进行更新迭代的，但是如果版本跨度太大，更新会更加繁琐和麻烦，很多自己还搞不定，并且未来兼容以及不确定因素太多，所以国产数据库的稳定性还是需要加强，兼容性也需要加强。我们用的OB和TIDB都是这样，版本迭代快，意味着问题也多。

好不好是相对的，不是绝对的，对于数据库厂商来讲为了快速变现，所以将一个基本能用的数据库上线；但是数据库到各个项目之后，各个项目的特性问题会直接暴露数据库的问题，这样就需要数据库厂商一直修改bug,导致 频繁升级 ，所以 频繁升级 对于数据库厂商为好事，它在完善；
但是各个客户这边用了一版数据库之后，如果出问题了，肯定不能等 升级的，一般都通过特殊处理绕过去问题的形式解决，时间久了就都不记得当时做的特殊处理了 ，这样再 升级数据库会出现很多的问题 ；
还有数据库最重要的就是稳定性， 一次升级就会存在诸多潜在问题，更别说 频繁升级 了，

版本更新太快肯定是不好的，说明版本也不稳定，很多bug，还不太成熟，虽然国产化是需要一段路，但是也不能给用户带来太多风险和坑，现在我用过的tdsql版本更新就很快，2019到2022，差不多从14到19大版本，中间小版本都没法统计，更新带来太多麻烦和风险。