数据库查询死锁

A. 一个数据库死锁竟然被测试发现了，这你敢信

在测试生产监控时，出人意料地发现了数据库死锁的报错：org.springframework..: 更新数据库时出现死锁，具体原因为com.mysql.cj.jdbc.exceptions.: 发现死锁。这个意外的发现源于一次测试讨论。

事情是这样的：老刘对理赔系统上线后的生产验证问题感到困惑，询问如何在测试阶段预防生产问题。我回应说，目前的生产验证依赖于业务人员，但测试团队决定调查可能的解决方案。在深入研究后，我偶然间遇到了EasyBI工具，这成为了解决问题的关键。

EasyBI是一个强大的生产数据统计工具，它支持连接生产数据库或通过接口开发，提供聚合表、透视表等图形化配置。我通过开发生产数据异常、理赔数量统计等接口，将其接入EasyBI，并配置成邮件订阅和定时任务，实时监控生产数据。其中，我特别关注的是错误信息统计接口，它能帮助识别错误类型，判断业务逻辑的合理性。

在开发过程中，我遇到的挑战是查询数据库时接口超时。为解决这个问题，我调整策略，将数据预先存储并进行校验，避免了频繁查询第三方接口。正是在错误信息统计时，我发现了数据库死锁的异常，显示了org.springframework..错误。与老刘分享后，他给出了赞赏。

这个经历提醒我们，通过有效的工具和持续的监控，即使是最微小的问题也能被及时发现，从而确保生产环境的稳定性和效率。我会继续努力，提升测试监控水平。

B. 如何查看MySQL数据库的死锁信息

查看MySQL数据库的死锁日志

1. 使用终端或命令提示符登录到MySQL，输入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p解释：xxxx.xxx.xxx是数据库IP地址，username是数据库用户名，输入命令后，会让你输入username对应的密码，就可以登录了

4. 如何分析日志，定位死锁原因看3里面的图，紫色划线部分分析：事务1，等待RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，这个位置的X锁事务2，持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁事务2，等待这个地方的X锁理论上这个事务2是可以提交的不会，死锁，但是这个事务日志只打印最后一部分死锁，信息，这里面隐含的条件是，事务1也持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`这个地方的S锁，这样，事务2不能加X锁，同时事务1也不能加X锁，产生死锁。