经常有数据库厂商的朋友和我谈他们的技术如何优秀，他们采用的共识算法怎么就比友商的优秀，他们的优化器如何智能，他们的高可用切换如何迅速，对听这些东西我是有点不耐烦的。这种情况下，我会故意拿出一些他们不擅长的场景，问他们这方面的能力如何。虽然会搞得有点尴尬，不过场面立马会务实许多。

我一直认为，不管数据库的技术如何先进，最终的目的是更好地解决用户应用中的问题，不为了解决用户痛点而泛泛地谈技术都是意淫 ，都是耍流氓。数据库用户不需要太懂某个数据库的内核如何先进，也不需要了解某个数据库的内核算法中是否有自己独有的专利技术。他们需要了解的是数据库产品能否有效地解决他的某个比较头痛的应用场景，比如：一条嵌套了十几层的SQL是否总能在某个数据库中生成出合理的执行计划;需要扫描1TB大表数据的SQL是不是能够很快跑出来;并发几万个会话的数据库能否稳定地运行不宕机;出现影响业务的慢SQL的时候能不能快速被定位并解决;硬件故障时能多块恢复业务;备份与恢复是否方便;运维监控是否易于掌握，等等等等。

曾经有数据库厂商和我说，某某竞品在某个用户那边又宕机了。我往往不为所动，干了三十年DBA，遇到的Oracle宕机也有几百次，自己不小心搞宕Oracle数据库的次数至少是两位数了，所以数据库不会宕机，不会出问题我是不相信的。

关键业务系统的数据库故障是依靠高可用架构来解决问题，而不是依靠数据库百分之百可靠的。任何一个数据库发生故障都是十分正常，只要没有因为数据库故障而引发业务事故，都是可以接受的，我不会因为某个数据库出现过某些故障而觉得这个数据库不靠谱。数据库不需要做到百分之百可靠，只需要做到遇到各种严重的故障，能确保关键业务系统在规定的期限内恢复运行就可以了。

前阵子有个朋友说某某大企业数据库国产化替代中用了某个数据库产品，有一次故障厂商搞不定，只能暂时回切到Oracle去了。我随后了解了一下，确实存在这个问题，不过几天后，问题解决，现在系统又切回国产数据库了。我觉得这件事反而验证了这个国产数据库产品是靠谱的，双轨制运行不就是为了保障此类问题的吗?这个案例反而说明了这套机制的有效性，让我敢于向更多的客户推荐在核心业务上用这个数据库产品了。

检验一个数据库产品是否优秀，并不需要看的技术水准有多高，说实在的 ，一个数据库产品的技术水准到达了何种高度，我也没有能力去鉴别，我的高度本身就不高，怎么能去衡量比我高出好几个身位的数据库产品呢?我只知道数据库技术是为应用服务的，应用能在上面运行得稳定与高效，数据库产品就差不了。屠龙刀虽然牛，找不到龙来屠，可能用处和切菜刀差别不大。看上去技术很先进，但是到了应用上就拉稀的产品不是好产品。

有数据库厂商的朋友和我说他们的数据库产品单机150万TPMC，我说：“又如何?客户的应用单机只需要10-20万TPMC就足够用了!但是有些存储过程，有10000-20000行，有的循环几千万次，每次处理一组数据，你的数据库能把其中最大的一个存储过程在2小时内跑完，我就考虑把它推荐给用户”。结果那个数据库在测试这个存储过程的时候跑出OOM，数据库实例宕了。

前些年受到互联网架构的影响，很多客户被互联网厂商教育了。应用不能乱写，要足够优化。应用优化我并不反对，以前我经常做数据库优化项目，其中最让人头疼的就是那些写得很烂的SQL。但是表连接不能超过3张表，子查询嵌套不能超过5层，数据库超过500G了必须分库分表等等。如果用户必须遵守那么多的规矩，那么我直接去用开源的MYSQL/PG好不好，为啥还要用你这种高档数据库呢?数据库产品的技术不应该只是体现在PPT里，而是应该让用户写得不算太好的应用能很好地运行才行。

数据库是用来处理数据的IT基础设施，而不仅仅是存储数据的容器，所以数据库产品一定要让用户处理数据这个工作变得更加简单才行。数据库厂商也不应该闭门造车，硬搞出一些不知道如何在实际应用场景中发挥作用的“新技术---名词”来。尺有所短寸有所长，每个数据库产品都不是万 能的，都有其优势场景和不足之处，扬长避短，让自己的产品找到适当的用户是数据库厂商应该认真去做的。片面夸大自己的技术，号称自己是万 能的产品，和这种厂商打交道时我一般都会多留点心眼。

数据库产品应该切切实实地在用户场景中去练练，看看哪些技术是真的有用的，那些根本没有实际用途的屠龙技，就别拿出去忽悠人了。