西安一码通的崩溃这个锅多半要由数据库来背

目前it界最大的新闻莫过于西安一码通的崩溃事件，这不仅是it圈的热点，也成为了全国瞩目的大事件，甚至连工信部总工程师都亲临现场。

许多IT界人士认为，责任不应该完全归咎于数据库，他们提出了以下两个理由：

第一个理由是，这个事件太大，数据库无法承担所有的责任。

第二个理由是从手机APP到数据库，中间有很多环节，不能单单说是数据库的问题。

然而，我认为这两个理由都站不住脚：

第一个理由显然不成立。正如大家所知，“成败在于细节”，业界许多大型系统的崩溃往往源于一个小小的bug。不仅IT项目如此，甚至一场大型战斗的胜败也可能由一个细节决定。

否定第二个理由需要从IT应用的通用架构说起。一个典型的IT应用的通用架构如下图所示：

西安一码通的网络配置大致也逃不出这个架构。西安一码通注册量达4000万，日均扫码800万次。这个压力在业界只能算是一般水平。分析一下应用的各个环节，数据库与其他环节有两个显著的不同之处：

各个环节（除了数据库外）随着负载的增加，处理时间会成正比延长，但数据库不同。一旦数据库的负载达到一个临界点，性能会呈指数级恶化！

其他环节的性能提升可以通过增加资金投入来解决，但数据库的性能需要通过技术手段进行优化才能大幅提升，再好的硬件也无法弥补烂SQL的问题！而且数据库很难进行水平扩展，通常只能在短期内进行纵向扩展，硬件升级的空间也有限。

从报道来看，在第一次全国瞩目的西安一码通崩溃后，该应用已经进行了升级，包括网络。由于这是一个重大事件，资金不会是问题。现在既然用钱无法解决问题，一个合理的推断是数据库的性能出现了问题。

再说一下应用容易产生烂SQL的原因有两个：一个原因是SQL通常由开发人员编写，而不是DBA，他们中的许多人不了解数据库，只是把数据库当成一个黑盒子来使用，仅关注数据存储而不考虑效率。另一个原因是SQL语言只需编写要做什么，而不需要编写如何做。把如何做交给数据库自己决定。这样烂SQL就经常产生，随便添加一个索引就可以让SQL的速度提高几百倍甚至几万倍。但西安一码通出了这么大的事情，谁敢进行变更呢？要知道，业界90%的事故都是由变更引起的。西安一码通虽然运行缓慢，但它还能运转，如果进行变更，可能会导致应用停止服务，这不是更糟糕吗？！

关于我：

姚远，Oracle ACE，华为云MVP，曾任IBM公司数据库部门经理，在数据库和相关领域拥有20多项技术认证。两次获得国家部级科技进步奖，并发明了两项计算机相关专利。