临时工说： 某数据库受难日之测试POC顺序有猫腻，说你不行就不行！

开头还是介绍一下群，如果感兴趣PolarDB ,MongoDB ,MySQL ,PostgreSQL ,Redis, Oceanbase, Sql Server等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群（共1620人左右 1 + 2 + 3 + 4） 3群已关闭自由申请如需加入请提前说明，新人会进4群（200）,另欢迎 OpenGauss 的技术人员加如入。

活明白了是很多人一生的追求，而更多人一生在追求到了追求后，反而希望自己糊涂一点，为什么，活明白和快乐之间，活明白的人选择尽量让自己快乐！

更换某个数据库进行各种前期的测试和比对是非常正常的事情，但是再正常的事情中，可以包含无数的你意料以外的事情，今天就所说最近遇到了一次有意思的数据库测试POC中的问题。

基于临时工天不怕，地不怕的日常行为规范，那个数据库就不说了，谁干的也就不说了，谁让咱们敢说呢？但是基于一些核心的问题，整体的过程一定是要说的清清楚楚，明明白白。

某企业基于成本和稳定性以及扩展性的需求，需要更换MySQL数据库到一个其他的数据中，基于整体应用不需要进行任何的改动，属于一个平替的方案。基于平替的方案中，需要进行测试的有以下部分

MySQL 与 某数据库的性能对比，其中分为压测软件性能对比评估和实际应用程序压测对比评估。在压测软件评估中，基本上某数据库和MySQL8.018 在多方面的性能比较上，占有优势，当然除了性能上还有一些其他的优势，这里就不表了，表多了就猜出那个数据库了。

但是业务部门对于这个压测的结果不置可否，对于平替的可能性和对应用的影响提出了很多的问题，并提出需要进行压测，通过业务压测全方位以生产作为一个POC环境的预想来进行压测。

实际上压测到业务上，某数据库也是不怕的，只要没有太多的??，基本上结果也是某数据库占优，所以针对列出来的一些压测方面的流程并未太多关注，评硬实力来说话，有信心。

但是在初期的压测中的确和数据库的生产商的给出的一些理论数据是一致的，随即迁移到了生产上，将一小部分的MySQL 替换成某数据库，然后进行更多的POC ，在通过业务接口进行压测的情况下，出现了问题。

1 压测中，通过业务压测软件得出了，某数据库的性能远低于MySQL8.018 

经过和某数据库的生产商进行沟通，以及DBA的研究，找了调整某数据库的参数，解决了这个问题，而这个问题的产生与业务的特殊性有关。

1 如果业务链接的数据是单点的情况下，无代理，则MySQL 给出了测试结果很好看，同时基于某数据库有代理的情况下，并且是多节点的情况下，导致业务快速的写入，在读取时去读了从库，（20ms）,从库这么短，并且大量写的情况下，有从库无法查到数据的情况，所以导致某数据库的错误率提到，并且由于应用读不到数据会发起第二次 ，第三次的读，导致业务感知到延迟的所在，让某数据库的在业务POC的这个大量写然后读的场景比较吃亏。

但基于某数据库的在代理上的可以进行调整的特性，DBA对于这块进行了调整，在次测试这个业务场景的情况下，之前业务报错频繁的情况就基本没有了。

但是随后产生了新的问题，因为在一个核心读的接口上，基于MySQL8.018 在压测读上，没有任何的错误，一会业务的报警，但是只要一换上某数据库，在进行压测，则这个数据库本身就出现无法读取的问题，并且业务大量的报错。

在经过DBA 和业务部门的分析，通过日志并未发现某数据库处于压力多大，拒绝服务的现象，反而是某数据库基本上负载不大，也就是MySQL一半负载的情况，随即测试人员抛出一个结论，某数据库性能有问题。

这里提醒某些数据库厂商，在终端客户进行POC的时候，如果业务POC 的测试人员给出这个结论，基本上你就死定了，结果自然是继续MySQL,你该哪里凉快哪里凉快，并且还的背负一个你不行的称号，并进行扩散性的散播此消息，最终导致你身败名裂。

不过某数据库的人品还是比较好，平时比较积德，DBA对于这个数据库的还是力挺的，并且对于这个评测的结果并不认为没有问题，立即提出各种针对应用软件可能存在的问题提出质疑。

当然一般来说，提出问题一般占有先机，业务部门对于一些提出的问题也不好解答，并且基于成本的因素，领导也希望更换掉MySQL,所以推动解决一些提出的疑问。

经过2天的问题排查，最终发现问题是测试顺序的问题，基于POC的压测，一定有对比，先压测谁，后压测谁看似没有问题，甚至很多人认为后压测有好处。但实际上不是，在压测中会制造测试数据，而压测中是有缓存的，应用中的缓存，在第一次测试中是干净的，所有压测是真实的，而在压测MySQL 后，在压测某数据库实际上是叠加的数据+新的数据，也就是某数据承受的工作量是第一次测试MySQL的 N倍，但此时应用程序发生问题，无法承受数据量，导致某数据库在第二次测试中，压力上不去，业务报错到达了，占整体业务60%的情况。

在发现这个问题后，业务部门进行了整改，同时DBA提出，先压某数据库，在压MySQL 数据库，然后结果就......... 

这里提醒某些数据库厂商，你们基本上是不会了解要上你数据库公司的具体的业务，以及业务特性，业务流程以及应用程序怎么处理这些问题的方式，POC 压测中制造数据，缓存数据，以及加压的等等的流程和猫腻。

所以如果你对你的数据库有信心，并且结果非常诡异的情况下，一定要提出一个问题，就是从来一遍，然后如果你是先压测的，那么就后压测一次，反过来也是一样，紧盯着整体测试中你的数据库测试中的排位情况，必须和对比的数据库，进行互掉测试顺序，尽量避免一些你不知道的测试中的陷阱。