互联网那一套现在在传统企业还是挺吃得开的。我经常会看到一些文章，比较MySQL和Oracle、PG谁的QPS高，谁的主键索引扫描得快。似乎读者也挺吃这一块的，这些文章的阅读量也还挺高的。甚至现在在一些用户做数据库选型的时候，对TPMC的高低，数据库扫描块的速度快慢等都十分关注。

前些年和一个银行用户探讨核心交易系统的选型参数时，他们提出来必须有500-1000万TPCC才能满足他们未来的发展需要，所以普通集中式数据库根本满足不了他们的需求。我掰着手指头和他计算500万TPCC的含义。他们目前高峰期一小时统计的交易频率大概是800笔/秒，全天平均值大概不到 400笔/秒。测算下来，高峰期也不过是4.8万TPCC的交易量(当然一笔银行交易直接折算为TPCC不够准确)，哪怕折算精度差了5倍，也不到25万。未来几年业务翻两翻，也不过100万。算完以后，他恍然大悟，自己是被人忽悠了。

前阵子和几个做了三十年IT的老朋友一起参加了一个传统企业某个具有互联网特征，日活差不多千万级别的APP去O的上线仪式。原本以为只是摆拍几张照片，以专注的神态配合拍上几段视频，熬个夜，在宣布成功上线的时候鼓鼓掌就完成任务了。没想到最后还上演了一场生死时速，几个老家伙的看家本领也被迫拿得出来，睁圆了一双双老花眼和近视眼，优化了几个模块，总算保住了成功上线的胜利果实。看样子传统企业玩互联网架构，还是缺了太多的东西了。要是更为复杂的传统特征业务也这么玩，估计把我们几把老骨头榨干了，也不一定搞得定。

传统行业的大多数系统都和互联网企业不同，其IT队伍的能力构成也与互联网企业相差甚远，用这支队伍来干互联网架构的事情，可能会力不从心。其实互联网企业的IT队伍，干起传统行业的事情来也不见得能如鱼得水。系统出问题的时候，那几个云厂商的现场服务专家基本上是全程懵逼的。当系统出现严重问题的时候，他们专家的建议是出问题的数据库做主从切换可能能解决问题。我当时觉得不解决掉那些逻辑读过高的SQL的问题，切了从库也没用，等业务重新恢复的时候，那些烂SQL的负载马上又会打爆那几个RDS的。

当时我正在给一张大表建一个缺失的索引，对这种没多大价值的优化动作十分排斥。不过在他们再三建议下实在拗不过，只好中断了正在创建的索引由着他们去折腾了。结果可想而知，在互联网企业的应用中常用的招数，在传统行业的应用场景里碰了一头包。用我们几个老家伙中的一个人的说法是，开发人员根本就不明白ORACLE和MYSQL有啥区别。在如此低下的开发能力加持下，互联网企业专家的经验根本无用武之地。

互联网企业在IT上的成功让他们去忽悠传统企业的时候自带光环，极容易让传统企业的IT人顶礼膜拜。判断忽悠还是真的NB其实不容易，自身的技术能力不足往往是被忽悠的主要原因。开发商让我帮忙看一条慢SQL。SQL很简单，一张1.5万左右数据的表和一张四百多条记录的表做JOIN，连接字段上还有合适的索引。以个人经验来看应该不会太慢，不过慢SQL抓到平均执行时间是20多秒，最高超过40秒。我在云管控台上直接执行这条SQL，平均执行时间很正常，70多毫秒。

对于慢SQL抓到的这种情况，我刚开始也有点不解，后来了解到数据库与应用之间还有一个隔离网闸，我们就把问题排查重点放到网闸上了。如果仅仅这条SQL目前来说风险还不算太大。数据库整体还可以，这条SQL是一个十分钟周期的任务中的，暂时不会影响客户体验。如果是隔离网闸存在问题就比较麻烦了。网闸出问题，整个系统都会变慢，这个问题就不是简单的SQL问题了。

我提出要查网闸的时候，开发商的DBA不大愿意了，他说互联网的专家研判后认为这SQL不可能和网闸有关，因为慢SQL是数据库内核抓出来的，不可能和网络有关。说得我有点烦了，有点冒火地说：这是哪个专家说的，你让他过来，我给他上上数据库原理的课。

通过给“专家”普及了一番SQL执行的原理后，专家也有点懵了，觉得我说的也许有点道理。我找到了网闸厂家，让他们写个测试程序，测试一下这条SQL通过网闸后的执行时间，最终确定我们这帮老家伙的经验还是要比互联网专家靠谱一些的。看样子，对于传统行业的系统，互联网专家的知识库也有点不够用。我这么坚持认为网闸可能有问题，不是我水平有多高，而是以前吃过这款网闸的亏。

对于绝大多数传统行业数据库应用而言，无需关注互联网企业对数据库的那种极致优化场景。传统企业也无需为每个QPS配置十分恰当的硬件资源，略微浪费一点也不会浪费太多资金，动态资源调整等高大上的东西在传统企业应用中收益也不足以抵消运维风险。传统行业的数据库使用，主要还是要关注数据库的可靠性、易用性、健壮性和对复杂业务的支撑能力等数据库发展了几十年的传统特性。

企业要从整体使用成本上去选择对自己的开发团队友好的数据库产品，从而最大幅度降低信息系统的全生命周期使用成本。有些系统，看似采用了互联网架构，使用了看似免费的RDS数据库，不过算算总账，可能多花了数倍的钱也未可知。在一些生产场景中，百多个RDS实例的使用效果可能还不如一套两节点RAC，算上高可用复制组的成本比较一下部署这些RDS所需的资源，可能省下大几百万也不够其他领域所浪费的。

对于传统行业的应用场景，传统行业的用户千万别被互联网思维给带歪了，应该更多地从应用场景的特点入手，选择能够更好地适配自己的场景，满足企业成本要求，同时自己的研发团队的能力能够轻松把控的系统架构。IT建设是个长期的系统工程，不是某个先进的理念就能够轻松颠覆的，踏踏实实稳步前行可能才是最好的道路。