数据库选型别只看宣传：外行看热闹，内行看门道

最近一点感受，主要不是说厂商，而是说用户

• 今天想跟大家聊一聊数据库选型这个话题，这也是我从业这些年，被身边同行、朋友问得最多，也最想好好拆解的一个核心问题——很多时候，面对同一款数据库、同一份厂商宣传，内行和外行看到的东西，完全是两个维度，甚至可以说天差地别。如果把宣传资料或者视频给我爸妈这样的看，他们觉得都很厉害。
• 从事数据库相关工作这么多年，市面上主流的、小众的、国产的、国外的数据库，我几乎都接触过、实操过，也踩过不少坑、避过不少雷。有时候静下心来想想，这种经历有点像《九品芝麻官》里那句经典台词：“小人世代为官，深知官场玄机”，只不过放到数据库这个领域，现在有些厂商的操作，真的是玄之又玄，让人摸不着头脑。
• 不知道大家有没有发现，现在很多数据库厂商，尤其是近几年崛起的国产厂商，宣传营销做得堪称“满分”。打开他们的官网、翻看他们的PPT、听他们的产品宣讲，满屏都是“行业领先”“性能无敌”“分布式天花板”“零故障切换”这样的关键词，配上炫酷的架构图、亮眼的测试数据，在外行人眼里，这简直就是无所不能、天下无敌的存在，之前我说过我看到过兼容Oracle超过100%。注意是超过啊。Oracle自己也只能做到100%。 总之吊打Oracle，冲出亚洲走向世界了。

透过现象看本质

• 但实际上呢？老话讲得好：外行看热闹，内行看门道。那些看似光鲜亮丽的宣传点，背后藏着的细节和代价，往往是外行人看不到、也想不到的，而这些被刻意弱化、甚至避而不谈的细节，恰恰是数据库选型中最关键的核心。
• 就拿大家最常被吸引的“扩展性”来说，外行看到厂商宣传“分布式架构，无限扩展”，第一反应就是“太先进了”“以后业务增长再也不用愁了”，觉得只要选了这款数据库，不管业务量翻多少倍，都能轻松应对。可只要你真的往深里挖一层就会发现——所谓的“无限扩展”，从来都不是没有前提条件的空中楼阁。很多时候需要代价的。当然中国人都含蓄。你含一半我蓄一半。你问了我就说，你不问我不说。就像我日常问开发，查询能不能带时间？开发说，业务没说。我也没问。
• 有的数据库扩展，必须是一组一组硬件批量扩容，单独加一个节点根本无法实现；有的虽然能一个节点一个节点扩，但扩容过程中，需要暂停业务、重新配置参数，甚至要修改应用代码；还有的扩容后，虽然节点变多了，但数据分片不均，反而导致部分节点负载过高、性能下降。这些扩展的形式看似都符合“分布式”的定义，表面上没什么问题，但扩展的代价是什么？对现有业务应用有没有侵入？扩容后的维护成本会增加多少？这些至关重要的问题，厂商在宣传时绝不会主动提及，外行人也根本看不出来其中的玄机。

广义兼容性和狭义兼容性

• 再说到另一个宣传重灾区——兼容性。几乎所有厂商都会拍着胸脯说，自己的数据库兼容性做得有多好，完全兼容主流SQL语法，能无缝替代Oracle、MySQL等传统数据库，迁移过程零成本、零风险。但实际操作起来你就会发现，很多时候，所谓的“兼容”，仅仅是保证你原来的SQL语句能正常执行、不报错而已。
• 至于这些SQL语句的执行效率，能不能跟在原来的数据库里一样快？复杂查询的响应时间会不会变长？事务的一致性、隔离级别能不能完全匹配原有业务需求？这些核心问题，厂商要么含糊其辞，要么干脆避而不谈。你不问，他就永远不提；你问了，他也只会用“基本一致”“大概率没问题”这样的模糊表述来敷衍。在外行看来，“能正常执行SQL”就等于“完全兼容”，会觉得“这个好啊，完全能替代我现有的系统了”，但只有真正实操过的内行才知道，这种“表面兼容”背后，可能藏着无数的性能隐患和业务风险，甚至会导致迁移后业务卡顿、数据异常，反而给运维工作添了大麻烦。
• 除了扩展性和兼容性，厂商还特别喜欢宣传“故障切换”能力，动辄就是“两秒秒切”“零感知切换”，在外行眼里，这又是一个“刚需亮点”——毕竟谁都怕数据库出故障，影响业务正常运行。可大家不妨静下心来想一想：一套正常运行的数据库系统，一年能发生几次真正需要切换的故障？如果一年能碰上一次，那这种切换能力还有点实际意义；但现实是，很多企业的数据库系统，一年都未必能遇到一次故障，甚至有些系统运行了五六年、七八年，都没有出现过一次因为硬件故障、软件崩溃而必须切换的场景。就拿我自己经手的几十套系统来说，最近五到十年，就没有出现过因为硬件问题而必须切换数据库的情况，偶尔出现一点小问题，重启一下就能解决，而重启的时间，也就一两分钟而已，对业务的影响几乎可以忽略不计。

理念很重要，除非主机被雷劈了，但凡能重启就不要切换

• 所以我一直有个观点：数据库真出了问题，优先处理问题本身，实在解决不了，重启就行，没必要过分追求所谓的“秒切”。反观有些厂商宣传的“两秒秒切”方案，说得很好听，但这种方案往往是“不讲武德”——它根本不管你切换过程中会不会丢数据、会不会出现事务中断。要知道，如果不考虑数据丢失、不考虑业务一致性，任何一个数据库都能做到“秒切”，但这种牺牲数据安全换来的“秒切”，对企业来说是有问题。。
• 其实把扩展、切换这些宣传亮点看透了就会发现，这些东西就像一张150分的考卷，最后两道大题，看着很难、很亮眼，但其分值也就占20分而已。很多厂商就靠着这20分的“难题”，把自己包装成“学霸”，吸引外行人的关注；可我们日常使用数据库，真正出问题、真正影响业务的，全是基础题——也就是这150分里的前130分。

第一性原理

• 大家心里都清楚，几乎没有哪个企业的数据库系统，是每天需要扩容、每天需要故障切换的。但外行往往就只盯着这20分的“难题”看，觉得只要能解决这些“高端问题”，就是好数据库，却忽略了最基础、最核心的日常使用体验。
• 那内行在数据库选型时，真正关注的是什么？我们不看宣传、不看PPT，不被那些花里胡哨的功能迷惑，我们关注的是优化器的性能——它能不能智能生成最优的执行计划，能不能高效处理复杂查询；我们关注的是执行计划的可调试性——出现SQL变慢时，能不能快速定位问题、优化语句；我们关注的是直方图的准确性——它能不能精准反映数据分布，为优化器提供可靠的依据；我们更关注数据库的可观测性——能不能实时监控SQL执行情况、锁等待、会话数、资源占用，能不能快速排查性能瓶颈、定位故障原因。
• 这些东西，外行人看不到，甚至连名字都没听过，厂商宣传时也绝不会主动提及，但这些才是我们日常运维工作中，每天都要面对、都要解决的核心问题。结果就是，很多企业花大价钱，选了一款“能解决几年才遇到一次的扩展和切换问题”的数据库，却每天都被SQL变慢、事务变长、锁等待、会话数飙高这些基础问题搞得鸡飞狗跳，运维成本翻倍，业务体验还越来越差。
• 当然不懂ACID、不知道CAP、不知道事务隔离级别，不知道索引，不了解各种锁的机制，丝毫不妨碍外行选型，但是带来的问题就是未来的各种问题。
• 我不是说数据库选型不需要关注扩展和切换能力，而是说，如果只盯着这些花里胡哨的宣传点，忽略了基础的性能、兼容性、可观测性，那就真有点买椟还珠了。

我还是喜欢一些实事求是的

• 最近OB和TiDB的和我交流，看了我的SQL样本都说，这种SQL没那么好处理。有点难，头大。不太行。可能有问题。要改。我反而觉得这种是我欣赏的。如果上来就说没问题，我反而怀疑在敷衍。
• 最后想跟大家说一句：数据库选型，从来都不是看宣传、看PPT、看亮点，而是要沉下去，看它的真实代价、看它的实际门槛、看它的日常使用效果。多做测试、多踩实测、多关注基础能力，才能选到真正适合自己业务、能省心省力的数据库——毕竟，适合自己的，才是最好的。