MYSQL解决不了的BUG

MYSQL解决不了的BUG

MYSQL灵异事件

• • MYSQL抽风事件起因
  • 事情归于平静
  • 诡异的事情发生了
  • 结论

隔离级别可重复读
某个时间点查询到了rollback的insert语句插入的数据

MYSQL抽风事件起因

21年12月31日，同事向我反馈了一个bug：公司一个后台（还未上线，一直运行，很少有人用 ）机器不能上传数据

我马上ssh连接服务器，查看了运行日志，果然发现了一个异常

以前写程序的时候考虑的不够全面，原来是公司租的一个旧服务器在7月份过期了，里面部署了rabbitMQ用来及时同步信息，而后台上传数据时，将同步信息和插入数据写在了一个@transactional注解方法中，rabbitmq连接超时一直报异常造成事务回滚。

找到原因后，我马上将方法解耦，这样即使rabbitmq异常也不会再影响事务正常提交，rabbitmq也在新服务器上重新部署，重新运行程序，查看日志，一切正常，大功告成。

事情归于平静

故事来到了1月4日，元旦休假归来。同事突然问我上次的问题如何了，我告诉他已经解决了，并亲自查询了数据库，大概新插入了1500条数据，查了几次，很满意，很舒适。

诡异的事情发生了

1月6日，星期四，突然心血来潮想检查一下上次出问题的后台，一查吓一跳，65条数据，心头一惊，糟糕出bug了
马上开始排查原因，先登录数据库，手动执行一下sql，没错就是65条
查看数据库用户权限，拥有所有表的所有权限
使用navicat连接一下，反复刷新，还是65条
找到后台日志，反复查看，没有发现异常
找到mysql通用查询日志（确实是开着通用查询日志），拖到本地，慢慢看
从12月31日-1月6日逐行分析（没错，我就是那么闲），没有发现rollback，没有发现delete
从服务器拿到这几天的sql备份，每天的数据量都是65条，难道是那天有人把1500条数据人删除？日志没有删除记录，所以那1500条数据从来都不存在

感觉整个人都不好了，我不会是梦游了吧，难道那1500条数据是我梦里的

又从头逐行分析，找到了我活在现实的证据，有一段反复查询数据的sql（没有显示结果行数），但是有limit限定条件30,15等等，证明是后台分页查询调用的sql，一次查15条，没错，里面有limit 135,15，证明了如果是65条根本不会显示那么多的页数从而能够调用这条sql，这是我查询出1500条数据过得铁证，
而且我确认过，那天查询出来的1500条记录确实是上传失败的那些数据（机器本地有数据库）

事情已经超出我的能力范围，咋整，确认了数据库事务隔离级别是可重复读
确认了没有rollback记录
确认了没有delete记录
确认了没有insert那1500条记录的日志记录
确认了后台不存在删除数据的接口
确认了除了我没人有权限 *** 作日志
好像那1500条数据不应该存在过，但是我确实查到过

结论

我是菜鸡，
菜鸡的结论是MYSQL抽风了，唯一可能的原因可能是，之前因为异常导致rollback的那些insert语句是那1500条数据的源头，可能是因为数据来了一趟时空旅行

我悄悄地走了就像我从未出现过，

我大胆的设想了一下，mysql的可重复读是在事务开始的时候创建一个快照，而那1500条数据会不会来至一个诡异的时间节点，
可是确实不太可能有时间节点提交1500条数据，因为一旦提交过就会一直存在而且日志也会有记录，除非有什么原因，导致读到了回滚的数据（1500条是由不同时间点1500次insert语句产生的），好像只能这么解释了

我撞鬼了.了.了.了

看来mysql隐藏bug也不少，偶尔来个灵异事件吓吓人，娱乐娱乐

有大佬遇到过或者知道原因可以留言哦，学无止境、永攀高峰