行锁问题，最有可能发生的是本身存在行锁等待链，比如某个会话锁定了一批数据，长时间没有释放。没有释放行锁的原因比较复杂，包括某个会话修改了数据忘了提交，数据库系统存在HANG的情况，性能存在问题，Oracle的闩锁等待等，都可能导致数据库系统出现较为严重的等待链问题。D-SMART中使用等待链分析工具来发现等待的根因，也是基于这个原理进行分析的。
为什么要用等待链分析而不是行锁链分析呢？行锁链分析只是等待链分析的一个子集。在某些纯粹因为行锁锁定引起的锁冲突场景中，行锁分析是可以发挥找根因的作用的，但是在一些比较复杂的场景下，等待链的主要原因是因为闩锁或者一些其他方面的性能问题，那么等待链分析就有更广泛的作用了。在Oracle当前问题诊断中，使用hanganalyze就是一种十分典型的等待链分析。
如果索引方面出现性能问题，那么数据库的行锁问题会被严重放大。如果在等待链中没有明显的问题，但是整个系统的行锁等待十分严重。
比如上面这个例子，行锁等待占到整个db time的65%以上，平均等待时间超过3秒钟。如果这是一个十分关键的系统，那么问题就十分严重了。实际上这是一个银行的核心系统。同时我们可以关注到，这个TX锁是index contention。这种情况在一些核心系统中经常遇到。在一些核心系统中的核心表上面经常会有很多个索引，7/8个甚至十几个。系统正常时还好，如果系统中的某些方面出现一些问题，比如IO延时、IO吞吐量、CURSOR等待等，都可能导致这些原本不会引起问题的索引冲突被放大，出现问题。索引冲突是由什么引起的呢？
子路径2.1：IO性能
IO出现性能问题，可能导致索引的写性能下降，虽然可能IO延时指标对数据库来说还算正常，比如5-6毫秒，但是有可能比平时高了一倍甚至更多，这种情况下，可能导致索引分裂的性能出现问题。
子路径2.2：叶节点分裂
叶节点分裂是当大规模的INSERT经常出现的场景，特别是我们的主键索引往往使用了sequence发生器，这种单边增长会导致十分严重的叶节点分裂。解决叶节点分裂导致的索引性能问题，可以采用hash分区表、加大pctfree、定期rebuild索引等。
子路径2.3：ITL等待
ITL等待是因为索引的事务槽配置不合理导致，可能ITL等待出现的次数并不多，但是其危害十分大。因为往往ITL等待的平均等待时间十分长，高达数秒钟甚至几十秒钟。解决这个问题的方法是设置合理的PCTFREE和INITTRANS参数。
子路径2.4：并发插入量过大
子路径2.5：同一张表上的索引数量过多
子路径2.6：BUFFER BUSY WAITS等待或者叫热块冲突。
如果表上的等待比较严重，也会直接导致严重的行锁问题。其主要路径如下：
子路径3.1：并发插入量过大
子路径3.2：热块冲突
子路径3.3：ITL等待
子路径3.4：IO性能问题
子路径3.5：主键字段的SEQUENCE性能问题
子路径3.6：表上的LOB字段性能问题
因为共享池性能问题导致的行锁等待出现的机会不大，不过如果共享池存在较为严重的问题，那么整个系统会变慢，从而放大行锁等待的问题。或者在某些时候导致短时间出现行锁严重争用。这对于一般的系统影响不大，不过对于一些实时系统可能会造成致命的影响。
子路径4.1：SGA RESIZE
子路径4.2：CURSOR等待
子路径4.3：ORA-4031
子路径4.4：DDL操作
系统换页会给大多数的数据库系统带来负面的性能影响，也会放大行锁等待的问题。对于原本行锁等待就较为严重的系统，会大幅度的放大这种影响。
