数据库性能的卖家秀和买家秀

     好几天没写了，这段时间积累了一点要说的问题。上周遇到华为的一个朋友，在提及数据库的时候很多性能指标。首先我不怀疑他的指标，我觉得十有八九就是真的。现在只要拿出的数据，基本都靠谱。因为如果离谱的数据，同行会质疑的。不过我说了一下就是在实际环境中，通常用户连这个百分之一的都达不到。这不是说产品不行，而是使用者不行。

     我们数据库从业者争论数据库性能看哪些指标，集中式还是分布式。（昨天看还到一篇文章写分布式和集中式的TPS和QPS等对比），至于看TPS、 QPS还是看RT等，一时半会很难说服对方。而我刚才说的实际环境中其实不管看哪个指标，都没达到。这是因为官方的数据都是实验室的理想数据，而实际环境是非常恶劣的。我国现状是应用开发人员对数据库不了解，需求怎么说我就怎么做。实际上需求的逻辑都错了，他也不管。再加上数据库没有好的设计，SQL几千几万行，甚至一个SQL上百MB也有。这些来自用户实际使用的毒打，导致数据库什么性能都是被摁在地上摩擦了。

     从前POC可能就是做几百条数据,现在大家被忽悠多了，都有心眼了.有可能测的时候数据量1000万级别甚至是上亿的数据量。曾经看到了几个国产数据库的厂商吐槽说用户测试他们的产品要求1000万的表不建立索引测试性能。厂商觉得委屈。但是其实这是我们国内现状。因为大部分业务场景即使用Oracle，也是没索引的。这就是国内现状。说白了只管功能，性能不是他的考核指标。只要功能逻辑对了就行。不过在我处理各个企业的一些问题时候发现。有的时候功能逻辑都不对。

    所以用户知道自己现状是什么，很少能控制开发质量的。那么在A数据库上乱写能抗住，那么换B数据库别指望应用开发改程序。一样乱写就看能不能支持了。不能支持的就不考虑了。

    这就是我说的数据库性能的卖家秀（认为设计师良好的，开发是高水平的），而实际上是只有厂商想不到的，没有开发人员做不到的。笛卡尔积了解一下？需要经历一下现实的毒打。

    我们看到TPCC的数据惊人，那是没见到我们真实环境的表设计、需求和SQL。用这个情况去套TPCC，别说打榜了。宕机不宕机还一说呢。

   华为有个朋友说，希望我提供一下真实用户的场景看看他们产品怎么预防。我看到了不一样的华为产品态度。他们不是说自己遥遥领先的那伙。我对他们的态度表示赞赏。我别的没有，这方面的血泪教训太多了，而这些在互联网公司是不多见的，这和企业的基因有关。

   基于以上的结论，乱写导致的性能问题，在分布式数据库上OB和TiDB等也会出现问题，这个和单机还是分布式没有关系。迪丽热巴穿的好看的衣服，一个200斤的人去穿，别说好看了，衣服会不会OOM被撑开都两说，这和单独上衣还是连衣裙没关系。主要是现状是大家身材管理都不到位。

   可能只有重视起来和管理到位才能减少和避免这类问题的发生，比如现在酒驾就几乎见不到了。到了这种时候，再谈数据库性能怎么测试以及分布式和集中式的性能。