目前IT圈里最大的瓜就是西安一码通的崩溃这个事情，它实际上也是目前全国最大的瓜之一，说全国人民关注也一点不过分，连工信部总工程师多都到现场了。
现在IT届的很多人观点是这个锅多半不应该由数据库来背，这里有两个理由：
第一个理由是这个瓜太大，数据库背不动。
第二个理由是从手机APP到数据库，中间环节很多，不能说是数据库的问题。
这两个理由我认为都是不能成立的：
第一个理由明显不成立，大家都听说过“成败在于细节”，业界太多大型的系统崩溃都是一个很小的bug造成的，不光IT项目是这样，甚至一场大型的战斗可能都是一个细节决定胜败。
否定第二个理由我们要从IT应用的通用架构说起，一个典型的IT应用的通用架构如下图：
西安一码通网络配置大致也跑不出这个架构，西安一码通注册量4000万，日均扫码800万次。这个压力在业界不能算大，只能算一般。分析一下应用的各个环节，数据库和其它环节有两个不同之处：
1. 各个环节（除了数据库外）随着负载的增加，处理的用时会成正比延长，但数据库不同，一旦数据库的负载增加到一个临界点，性能会成指数级恶化！
2. 其它环节的性能的提升都可以用钱解决，只有数据库的性能需要通过技术手段进行优化才能大幅提升，再好的硬件也救不了烂SQL呀！而且数据库很难进行水平扩展，通常短期之内只能进行纵向扩展，硬件的升级空间也有限。
从报道看在第一次全国瞩目的西安一码通崩溃后，这个应用已经进行了升级，包括网络，像这么大的事情不会缺钱的，现在既然用钱没有解决问题，一个合理的推断是数据库的性能出了问题。
再说一下应用容易有烂SQL的原因有两个：一个原因是通常SQL是开发人员写的，而不是DBA，他们很多人不懂数据库，把数据库当成一个黑盒子用，只是存放数据，不管效率。另一个原因是SQL语言只需编写要做什么，而不需要编写如何做。把如何做交给数据库自己决定。这样烂SQL就经常产生，随便加一个索引就可以让SQL快几百倍甚至几万倍。但西安一码通出了这个大的事情谁敢做变更，要知道业界90%的事故都是变更引起的，西安一码通是慢，它还能运转，如果进行变更，这个应用停止了服务不是更糟糕？！
关于我：
姚远，Oracle ACE，华为云MVP，曾任IBM公司数据库部门经理，在数据库和相关领域有20 技术认证。两次获得国家部级科技进步奖，发明过两项计算机相关专利。
