MYSQL 有些软件设计，我不知道你怎么想的？

事情是这样的，公司里面有一个买来的软件，（软件公司名，功能就不提了，以免让人家不快，虽然能把软件写成这样，也值得曝光）。

公司里面的别的IT 部门的员工，问我这个MYSQL 怎么这么不稳定，一会儿有数据，一会儿没数据，这个东西不稳定呀。OK MYSQL 不稳定，MYSQL 不稳定去年人家是NO1 好吧。但是不能流露出某些表情，"内存"的活动还是留在心里最好。

将他给我的mysql以及相关的表进行了一个初步的人肉的测试，发现的确是查询一个表，有的时候有数据库，有的时候没数据，好怪，心里一万只，可爱的神兽。

具体的情况是，一个数据库某些表，一会儿查询数据库的某张表可以select 出来数据，一会不可以select 出来数据，不可以select 数据表给出的结果是 empty set.

这不科学呀！到底是怎么回事。

当前情况与分析问题

1 当前的数据库表，的确是有时无法访问到数据库表，有时的时候可以访问数据

2 其他的表有的时候也有类似情况

3 能查询数据和不能查询数据的时间间隔不固定

根据上面的问题，去查看错误日志，也是没有收获，说明mysql并没有因为严重的错误，而造成系统性的错误，所以先将MYSQL本身有问题的可能性排除，或降低到较低的水平。

那可能的错误的位置在应用层，正常的命令导致错误的事情也不少见，看看到底这个MYSQL 服务器承接了什么操作？？？打开genernal log 一段时间，通过查看里面的执行的语句，发现了有点意思。

下面是模拟这个MYSQL 服务器上所遭受的“挫折” （或许仅仅是部分的）

先创建一个库，然后生成 3 - 4 个这样的存储过程（其实用python写更好）

存储过程是一样的，只不过存储过程的名字， 创建数据表的名字，以及 replace into 数据的表名都要更改。然后一起运行（也可以多个存储过多往一个表里面写，但我没有这么做）。

下面有三张表分别叫 big_data big_data1 big_data2

三个存储过程，myproc() myproc1() myproc2() 里边除了表名不同其他都一样

然后执行三个存储过程，存储过程在执行的时候，明显 big_data 数据可以查询，但big_data1 的表只能查出一条数据， big_data2 表干脆就反馈empty set

首先我不大理解的是通过genernal log 查看，为什么这个软件一直要在数据库里面执行

set global autocommit = 0 ; replace into xxxx ; set global autocommit = 1; 整体数据库的 commit 全部乱套了。

导致查询数据库的 autocommit 一会儿on 一会 off

可能用存储过程来模拟软件，还是缺乏严谨性，因为软件里面的一些架构或者设置在存储过程里面是没有办法设置的，模拟的。但实际上，一个软件在出厂的时候，难道不应该做一下测试，发现一些问题。

单线程可能不会出现任何问题，只要一并发，多线程，事情就变得越发的复杂，很可能就远超，脑洞可控的范围。

另外我怀疑是拿ORACLE 里面不自动commit 的概念用到了 mysql 里面，这里四大数据库，只有ORACLE 一个奇葩默认是自己不commit 其他的数据库 MYSQL , POSTGRESQL , SQL SERVER ，全部默认是自动提交。另外如果从事务的角度看，如果想批量插入数据一次性commit 也是可以理解的，但单条语句也没有必要这样操作，所以这个软件的脑洞，我实在是不理解。

当然上面的测试从严谨性来说，还有很多问题存在，例如一会有数据，一会没数据，从gernal log 里面也看到，除了插入数据，同时也在delete 数据那些被查询的表，具体是怎么个逻辑，估计只有设计者明白。

借用三体里面的概念， 我这个问题的发现，解决者站在二位空间努力了半天，解决发现问题，人家软件的开发者，在三维的空间，大笔一挥就让我晕头转向，这属于降维打击，不科学。（软件是多线程并发处理，而general log 只能给我一个顺序性的日志，所以人家是三维立体，我这看general log 属于二维空间）

但有一点，MYSQL 不稳定，数据库有问题，这点 It's totally bull shit