首批通过分布式安全可靠测评,为关键业务系统打造
OceanBase 数据库集群内简单 SQL 语句因 -6004(lock_for_read need retry) 变慢的原因和解决方法
更新时间:2026-05-14 09:21
问题现象
在 OceanBase 数据库集群内,某些简单的 SQL 语句突然变慢,日志表现为 -6004 异常等待。
[2024-08-21 18:55:38.847056] WDIAG [STORAGE.TRANS] ob_memtable_context.cpp:409 [33428][0][xxxx-xxxx-xxxx-xxxx] [lt=8] [dc=0][errcode=-6004] lock_for_read need retry(ret=-6004, *this=alloc_type=0 ctx_descriptor=0 min_table_version=0 max_table_version=1723222694410248 is_safe_read=false read_snapshot=1724237737939741 start_version=-1 trans_version=9223372036854775807 commit_version=0 stmt_start_time=1724237737950097 abs_expired_time=1724241337880131 stmt_timeout=3599930034 abs_lock_wait_timeout=0 row_purge_version=0 lock_wait_start_ts=0 trx_lock_timeout=-1 end_code=0 is_readonly=true ref=0 pkey= trans_id= trans_mem_total_size=0 checksum_log_ts=0, *mem_ctx=alloc_type=0 ctx_descriptor=112552661 min_table_version=1708704838476680 max_table_version=1708704838476680 is_safe_read=false read_snapshot=1724237721811583 start_version=-1 trans_version=1724237737148950 commit_version=0 stmt_start_time=1724237721811009 abs_expired_time=1724241321711500 stmt_timeout=3599900491 abs_lock_wait_timeout=1724241321711500 row_purge_version=0 lock_wait_start_ts=0 trx_lock_timeout=-1 end_code=0 is_readonly=false ref=0 pkey={tid:1100611139455225, partition_id:0, part_cnt:0} trans_id={hash:12218919584240162027, inc:5894164303, addr:"10.20.140.22:2882", t:1724237700192074} trans_mem_total_size=47631815 checksum_log_ts=0, version=1724237737939741)
问题原因
OceanBase 数据库在查询某个表的数据时,会获取一个数据版本号 A,如果此时存在一个处于提交状态单未完成的事务(事务版本号为 B 且 B 小于 A),当该查询读取版本号 A 的数据时,需要等待事务提交结束(等待读取版本号为 B 的数据行),此时会出现 lock_for_read 等待。
问题的风险及影响
造成查询耗时长、租户 CPU 跑满、业务响应慢等情况。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
适用版本
OceanBase 数据库 V2.x、V3.x、V4.x 版本。
解决方法及规避方式
控制大事务的大小。
优化大事务的执行时间。