基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。
读写冲突导致的性能问题
更新时间:2026-05-14 07:41
适用版本
OceanBase 数据库所有版本。
问题现象
Query 偶发性能问题,经排查不存在访问路径的变化。搜索问题执行的相关日志,发现存在 lock_for_read need retry 的告警信息。
[2023-09-01 16:24:12.822805] WARN [STORAGE.TRANS] wait_trans_version (ob_memtable_context.cpp:402) [80065][0][YB42C0A8011A-0005F9FFDDB72C73-0-0] [lt=17] [dc=0] lock_for_read need retry(ret=-6004, *this=alloc_type=0 ctx_descriptor=660875988 min_table_version=0 max_table_version=1691887712554976 is_safe_read=false read_snapshot=1693556616209779 start_version=-1 trans_version=9223372036854775807 commit_version=0 stmt_start_time=1693556616350887 abs_expired_time=1693592616138492 stmt_timeout=35999787605 abs_lock_wait_timeout=1693592598781329 row_purge_version=0 lock_wait_start_ts=0 trx_lock_timeout=-1 end_code=0 is_readonly=false ref=1 pkey={tid:1102810162817318, partition_id:3, part_cnt:0} trans_id={hash:5323857072658908736, inc:2575819586, addr:"192.168.1.26:2882", t:1693556552169329} checksum_log_ts=0, *mem_ctx=alloc_type=0 ctx_descriptor=662802493 min_table_version=0 max_table_version=1691887712554976 is_safe_read=false read_snapshot=1693556597402967 start_version=-1 trans_version=0 commit_version=0 stmt_start_time=1693556597732304 abs_expired_time=1693592597332232 stmt_timeout=35999599928 abs_lock_wait_timeout=1693592543036230 row_purge_version=0 lock_wait_start_ts=0 trx_lock_timeout=-1 end_code=0 is_readonly=false ref=0 pkey={tid:1102810162817318, partition_id:3, part_cnt:0} trans_id={hash:2656401612840724845, inc:2575807169, addr:"192.168.1.26:2882", t:1693556463399201} checksum_log_ts=1693556582221670, version=1693556616209779)
问题原因
Query 要读取的表上存在大事务进行批量数据更新、删除,发生了读写冲突,Query 需要等待事务提交完成。
解决方法
缩小大事务修改数据量,分批提交,来加快事务提交的速度。
关于读写冲突
读写之所以会冲突,是因为该语句的 read_snapshot_version > 该事务的 prepare_version,但 commit version 不确定。换言之,需要等该事务形成 commit version 之后,才能决定是否要读到该事务的修改。