关于数据库的应用，总有两派观点，一派是数据库要那么强的能力干嘛，数据库的问题都可以通过应用来解决，系统性能不行，肯定是应用没开发好。而另外一派则是数据库太垃圾，应用跑起来就太费劲，一定要选一款强大的数据库来支撑应用，数据库不行，所以系统就慢。实际上从各自的角度来说，这两者都没错，二者不能相互理解，那是因为二者面临的实际情况不同。今天一早就在高铁上，就简单聊几句这个问题吧。

我对上面这个问题的看法是，应用的性能问题往往出在应用开发团队能力可控制的范围之外，当系统的复杂性对于研发团队来说是可控的情况下，系统性能问题也是可控的;而当系统的复杂性超出了研发团队的可控范围的时候，性能问题必然会变得复杂。也就是说开发团队的能力与特点决定了数据库应用的基本面。因此不同的人有不同的观点就十分正常了，这是各自认知的世界以及对这个世界的立场和观点不同决定的。

用这个观点来分析全面的二者的时候，可以如此解释，前者的能力能够把控应用当前的复杂度，因此他们不需要借助数据库的能力就能解决应用中的复杂性问题。而当系统复杂度，负载等持续增加，有一天超出团队能力的时候，他们也会发现他们可能需要选择能力更强的数据库来支撑他们了。这一点最近在一些做实时数仓应用的团队中经常遇到。在选型的时候觉得hudi不错，而用了一段时间发现，某些hudi不太强的地方Drois其实也不错。实际上大多数开源项目都不一定能够完美的契合我们的应用，这时候我们必须通过自己的应用来适配这些开源产品。商用产品则在这方面好一些，因为商业利益驱动了厂家不断地去满足多样化的用户的需求。

前些年有个用户和我说，自从他们把数据库从 Oracle 迁移到云上的 RDS MYSQL，他发现他们的研发团队水平太差了，因此这些年他重点抓研发团队的能力提升，也用重金聘请了一些在MySQL开发上水平较高的架构师加入他们。随着开发团队能力的提升，现在他们已经能够应对云上RDS出现的各种问题了。

另外一个例子也是从ORACLE向RDS MYSQL迁移，用户以前的核心系统都在ORACLE上，经常出问题，经常需要对应用与数据库进行优化，即使如此，系统故障，宕机等现象还是无法杜绝。这些年企业推进系统上云，很多新建系统都用了云上的RDS。RDS使用起来很方便，系统上线后运维也挺方便的，因为RDS上跑的系统都不大，所以也没有遇到什么运行上的问题。于是企业的IT部门领导认为RDS是比ORACLE更好的数据库解决方案，推进把一些较为复杂的关键系统也向RDS MYSQL迁移。不幸的是，他们的研发队伍还是当年把ORACLE都用得经常出问题的那帮人，对业务很熟悉，但是SQL写得很随意。当一些稍微复杂一点的系统被迁移到云上后，他们发现原来使用Oracle的时候系统存在的问题依然存在，甚至系统的性能问题更严重。这下子麻烦大了，以前使用传统架构的时候，优化SQL、优化数据库还是有套路的，上云后，以前的优化套路也失效了。他们被一个新的，更难解决的问题完全困住了。

能不能把应用搞好，研发团队的技术水平十分关键，研发能否把控系统的复杂度，是否了解底层基础设施，很好的掌握与利用数据库等的特性，也十分关键。今天我要表达的观点是，比起研发队伍的能力来说，IT主管部门领导对自己研发团队的能力边界的认知更为重要。如果不了解自己的能力边界，盲目的推行某些技术路线，选型数据库产品，对于一个组织来说是十分危险的。