摘要：对比左右两份日志，发现是同一个事务 ID ， TRANSACTION 367507261 ，事务持续了 7 分钟。对应 update 了两个表，左侧执行 update A ， 右侧执行了 update B 。开发排查代码发现， A 表 和 B 表不在一个接口里

核心应用 pod 发生重启，同时接收到对应使用者反馈业务问题，开始排查。

1、根据重启应用信息，查询 APM 执行数据库 update 操作大量报错，执行时间在 5min 以上。

分析 APM 链路异常，发现是触发了数据库的等锁超时，结合数据库等锁超时时间为 5min ，符合预期。

2、查看对应数据库指标，问题时间段等锁耗时、行锁、每秒锁表数据指标异常， 并且在 11:13 分出现死锁。

3、日志关键字搜索“Deadlock”，发现有数据库出现死锁，发现 11:13 分有死锁日志。

数据库死锁，导致了本次故障发生，需要进一步分析死锁出现的原因。

数据库死锁日志的部分截图。

这里，首先应该确认的一点，数据库事务 ID 是不会出问题的（期间也怀疑过，找 DBA 确认过数据库无问题） ，那极有可能是事务混乱了，应用使用的 spring 框架，使用的是 HikariCP 的数据库连接池，连接池是多线程的，现在假设一种场景，请求 1 使用了一个数据库线程，开启了事务，但是并没有提交事务就结束了，这个线程放回线程池，过了一段时间请求 n 进入直接进入了这个事务， 并开启了子事务进行数据库操作，那么就极有可能发生死锁如下图：

开发复盘整个代码， 发现有代码在 controller 层显示开启了事务，也有显示的提交，但是中间存在逻辑漏洞会直接 return 不关闭事务。

观测云查询作证，确实执行到“查询失败”直接返回到逻辑。 和猜想一致。

对比链路，正常链路会有一个 SELECT， 随后跟一个 UPDATE 。

异常链路中，仅执行了 SELECT ，可以判断，没有执行事务提交操作，从链路关联的日志中，也能佐证这一点。

来源：甜甜圈科技