应该是有其他大事务把 id=220269386 这条记录锁住了。
锁住的可能有几种，update 的条件命中 id=220269386 或者 lock_status = 4 或者 lock_etime=1726041977 都会锁住这条记录，可以看一下慢查询日志

给你个极端的原因，定期 roll 日志文件的时候 io 塞住了

随机卡，还一卡卡那么久，考虑是随机数生成器问题了.
-Djava.security.egd=file:/dev/urandom

mark 跟踪一下，有思路麻烦各个吴彦祖踢我一下

日志的内容里面耗时这个是当前时间减去 startTime ，startTime 在哪定义的，从截图看并不知道，那么截图里高亮的两个“当前耗时”和“耗时”没有可比性，先忽略。

17.039 的是 updateTagsModuleLibsById 的日志
18.080 的是 updateModuleLibById 的日志
不是两条相邻代码的日志。

updateModuleLibById 方法没有产生 sql 日志。
没有任何不合理之处。

接口延迟，只是 updateModuleLibById 处理时间长了，要查一下这个方法为什么在特定时间，比如刚过 16 点的时候，会有延迟。