update只要更新到同一行，就会造成行锁吧，应该是和走那个索引无关的，解决锁的问题，只有更新完commit后才能解锁(人工干预就是kill会话，但是如果没有commit，会回滚，如果数据量比较大，可能会造成undo不足或者影响性能，kill会话前一定要考虑清楚)。还有就是可以考虑做下业务调整，这种更新操作，可不可以放到非业务高峰期来进行。个人意见，可以参考下

update后面的条件筛选出来的记录是唯一的，怎么会造成更新到同一行呢？

您可以看下执行计划中，显示逐渐索引字段执行了INTERNAL_FUNCTION，应该是Oracle进行了隐式转换，不能使用索引，进而导致执行慢，大量同行请求进来的时候，行锁不能释放，导致row lock contention增加。因此，可能解决了隐式转换的问题，row lock contention就可以下降了。

P.S. 很可能是你的字段定义，VARCHAR2和NUMBER的关系，导致了隐式转换，可以看下。

是的，说回来了，也就是说不走索引，走了全表扫描造成执行效率低，导致的enq: TX - row lock contention增加。
并不是由于多个sql操作了一条记录产生的enq: TX - row lock contention，对吧

enq: TX - row lock contention，是对相同行操作产生的行锁争用，我的意思是之所以会产生争用，很可能是因为全表扫描，对行锁的持有时间增加了，才导致的，如果SQL高效，很快释放了行锁，即使多个SQL操作同一行记录，并不会产生争用，因此，您说的后半句，不是很准确。