一次 select for update 的悲观锁使用引发的生产事故

1.事故描述

本月 8 日上午十点多，我们的基础应用发生生产事故。具体表象为系统出现假死无响应。
查看事发时间段的基础应用 error 日志，没发现明显异常。查看基础应用业务日志，银行结果处理的部分普遍很慢，大都在十分钟以上。

2.AWR 报告

向 DBA 要了一下那个时间段的 AWR 报告，发现以下三个地方有些异常：

2.1.CPU 利用率过高

如上图所示，CPU利用率：1883.25分钟DB时间/(16核心*119.45分钟采样时间段时间) = 98.54%，CPU 利用率过高。

2.2.行锁等待严重

如上图"Top 5 Timed Events"所示，行锁等待占用了 80% 的 CPU 时间，基本可以确定它就是造成本次生产事故的直接元凶。
所以我们直接跳到"Wait Events"排行榜：

这说明了什么？在本次 AWR 报告的 09:00:45 - 11:00:12 大约 119.45 分钟的时间里，行锁等待的时间为 99974 秒，合 1666.23 分钟！
2.3.悲观锁慢查询严重
那么是什么操作造成行锁等待如此之严重呢？如此严重的行锁等待，慢查询统计列表里