高并发下OceanBase(MySQL模式)分区表Lock wait timeout异常排查

阿华AIGC实验室

2026-6-2

OceanBase分布式锁超时问题诊断与解答

问题背景

将高吞吐量交易表tx_order从标准MySQL迁移至OceanBase 4.x（MySQL兼容模式），表基于created_at做RANGE分区，复合主键为order_id + created_at。在3000-4000并发TPS负载测试中，如下简单UPDATE语句间歇性出现锁超时：

ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

问题SQL：

UPDATE tx_order 
SET order_status = 'PROCESSED', updated_at = NOW() 
WHERE order_id = 'TX_9823741' AND created_at = '2026-06-01';

已确认ob_trx_timeout和ob_query_timeout配置合理，且MySQL环境下相同负载无此问题。

OceanBase作为分布式数据库，锁机制在分布式场景下存在核心差异：

锁的分区级管理：MySQL的意向锁是表级粒度，而OceanBase针对分区表会使用分区级意向锁，访问分区时需先获取该分区的意向锁，高并发下若多个事务竞争同一分区的意向锁，可能累积等待延迟。
分布式锁协调：MySQL的行锁完全在单节点内管理，而OceanBase的行锁由数据所在的OBServer节点持有，即便SQL定位到单个分区，事务的锁生命周期（如2PC阶段）也可能比单节点MySQL更长。
Gap锁与Next-Key锁的实现：OceanBase在MySQL兼容模式下的RR隔离级别，Gap锁的范围判定与MySQL存在细微差异，针对分区表，可能在分区边界处产生额外的锁范围，导致意外的锁冲突。
锁释放时机：MySQL在事务提交/回滚时立即释放锁，而OceanBase的分布式事务需完成2PC的commit阶段后才会最终释放锁，若网络或节点延迟，锁持有时间会被拉长。

这个问题大概率与这两个因素相关：

全局索引维护：如果tx_order表存在全局索引（非本地分区索引），更新主表行时需同步更新全局索引数据。全局索引的分区策略通常与主表不同（如哈希分区），这意味着更新操作需要跨多个OBServer节点加锁，高并发下节点间的锁协调延迟极易引发锁等待超时。
2PC协调延迟：OceanBase的分布式事务采用2PC协议，事务的prepare阶段需要协调所有涉及的节点完成锁确认，若某个节点负载过高（CPU/IO/网络瓶颈），会导致prepare阶段耗时增加，事务持有锁的时间被拉长，后续事务的锁等待时间超过ob_lock_wait_timeout（注意：该参数独立于ob_trx_timeout）时就会触发超时。

GV$OB_LOCK_WAITS：查看当前所有锁等待关系，可获取等待会话ID、持有锁的事务ID、锁类型、涉及的表/分区/行信息，直接定位阻塞源。
GV$OB_TRANSACTIONS：查看所有活跃事务的状态，包括事务启动时间、是否处于2PC阶段、涉及的分区数，判断事务是否因分布式协调延迟未及时释放锁。
GV$OB_LOCKS：查看所有已持有的锁，包括锁的粒度（行级/分区级）、锁模式（X/S/IX/IS）、所属节点，排查是否存在不合理的锁范围。
GV$OB_SESSIONS：结合锁等待信息，查看阻塞会话的当前执行SQL、连接时长、资源占用情况。
GV$OB_PARTITION_LOCKS：针对分区表，查看分区级的锁持有情况，确认是否存在分区级意向锁的竞争。

定位锁等待具体场景：
执行SELECT * FROM GV$OB_LOCK_WAITS，锁定出现超时的时间段，查看等待的锁类型、持有锁的事务ID，关联GV$OB_TRANSACTIONS查看该事务的执行状态与耗时。
排查全局索引影响：
执行SHOW CREATE TABLE tx_order确认是否存在全局索引，若有，尝试临时禁用全局索引后重新压测，观察超时是否消失。若消失，可考虑将全局索引改为本地分区索引（与主表同分区策略），避免跨节点锁协调。
检查节点负载与2PC状态：
通过GV$OB_SERVERS查看各节点的CPU、IO、网络负载，定位是否存在性能瓶颈节点；同时查看GV$OB_TRANSACTIONS中TRANSACTION_STATUS字段，若大量事务处于PREPARING状态，说明2PC协调存在延迟。
调整锁相关参数：
若确认是锁等待时间不足，可适当调大ob_lock_wait_timeout；若业务允许，将事务隔离级别从RR改为RC，减少Gap锁带来的锁冲突。
验证执行计划正确性：
执行EXPLAIN UPDATE tx_order SET ... WHERE ...，确认SQL是否走复合主键索引，是否精准定位到单个分区，避免因执行计划错误导致的全分区扫描与锁范围扩大。