<p>enq: TX - row lock contention 是会话等待另一会话释放某行TX锁的行级并发阻塞事件，非死锁但更隐蔽常见；它不立即报错，而是默认等待60秒，期间会话处于WAITING状态，导致请求排队、超时及应用“点不动”，需通过v$session查blocking_session与rowwait*定位锁链源头。</p>
enq: tx - row lock contention 直接拖慢系统响应，不是因为锁本身耗资源，而是它让后续请求排队等、卡住、超时，最终表现为应用层“点不动”“查不出来”“提交失败”。
enq: TX - row lock contention 是什么，为什么它不“立刻报错”
这个等待事件表示：一个会话正在等另一个会话释放某一行的事务锁（TX锁），而不是等表级锁或对象级锁。
它本质是行级并发阻塞，不是死锁（Oracle能自动检测并回滚死锁一方），但比死锁更隐蔽、更常见。
- 它不会立刻报
ORA-00060，而是安静地等——默认等 60 秒（由DDL_LOCK_TIMEOUT或隐式事务超时控制），期间会话状态是WAITING，SQL还在跑，但没进展； - 等待期间，该会话占用 PGA、持有 latch、可能还占着 shared pool 中的 cursor，其他依赖它的会话也跟着堵；
- AWR 报告里看到
Total Waits高、Avg Wait(ms)超过 100ms，就说明已有明显阻塞链。
怎么快速定位哪条 SQL 在“卡别人”和“被谁卡”
不能只看 Top SQL，得结合锁链源头查：
- 先查当前阻塞关系：
SELECT blocking_session, sid, serial#, event, sql_id FROM v$session WHERE event = 'enq: TX - row lock contention';
- 再查被阻塞者的 SQL 和锁对象：
SELECT s.sid, s.sql_id, s.row_wait_obj#, s.row_wait_file#, s.row_wait_block#, s.row_wait_row# FROM v$session s WHERE s.sid IN (SELECT blocking_session FROM v$session WHERE event = 'enq: TX - row lock contention');
- 对应对象名用：
SELECT owner, object_name FROM dba_objects WHERE object_id = &row_wait_obj#;
注意：row_wait_block# 和 row_wait_row# 可定位到具体数据块和行号，但生产环境一般不直接查行内容，优先看 SQL 是否在热点主键/唯一键上做 UPDATE 或 SELECT FOR UPDATE。
常见诱因和容易踩的坑
-
INSERT /<em>+ APPEND </em>/和普通 DML 混用：APPEND需要 TM 排他锁，若同时有普通UPDATE在同一张表上，极易触发enq: TX等待； - 应用层没设事务边界：比如 Java 里用
@Transactional但方法体过大，或忘记 closeResultSet/Statement，导致事务长时间不提交； - 外键列缺失索引：子表插入/更新时需校验父表存在性，若外键无索引，会锁全表或大量块，间接拉长 TX 锁持有时间；
- 使用
SELECT FOR UPDATE NOWAIT但没处理ORA-00054：应用重试逻辑写成死循环重试，反而加剧争用； - 分区表局部索引失效：某个分区数据倾斜 + 索引失效，导致所有 DML 都挤在少数 block 上，形成“热块+热行”双重锁争。
真正麻烦的不是锁本身，是它藏在业务逻辑深处：一条看似简单的订单状态更新，可能因为上游没提交、下游重试机制失控、或者缓存与 DB 不一致，演变成跨服务的锁传播。查 AWR 时盯住 Segments by Row Lock Waits 和 Top SQL 的 Rows Processed 与 Executions 比值，比单纯看等待时间更有诊断价值。
