Queuing 表运行使用机制

OceanBase 数据库 V3.x 版本，业务表模式修改为 Queuing 表（Buffer 表）后，仍存在多版本读放大引发的性能线性回退问题，需补充运维转储规避。

详细说明

关于 Queuing 表转储

OceanBase 数据库的自适应的 Buffer 表转储策略，由存储层在每次转储时根据转储的统计信息来自主判断是否需要对该表采用 Buffer 表转储策略，当发现一个表存在类似 Buffer 表行为时，接下来会尝试对这个表做 Buffer Minor Merge 的调度，对这个表基于 Major SSTable 和最新的增量数据以当前的读快照时间生成一个 Buffer Minor SSTable，这次 Compaction 动作会消除掉增量数据里的所有 Delete 标记，后续查询基于新生成的 Buffer Minor SSTable 就可以避免原有的大量无效扫描动作。

Buffer 表转储策略判断依据： 同时满足 _ob_queuing_fast_freeze_min_count（默认值 500000）&& _ob_queuing_fast_freeze_min_threshold（默认值 10%）。

触发条件： Minor Merge。

问题现象

业务表模式修改为 Queuing 后，表中大量插入的同时大量连续删除（或者大量更新，因为大量更新同样会导致版本节点持续增长并带来读放大；仅在某些特殊场景（如更新主键）下，更新会表现为删除加插入）时，满足 _ob_queuing_fast_freeze_min_count && _ob_queuing_fast_freeze_min_threshold 判断依据，SQL 耗时仍持续线性增长。 GV$SQL_AUDIT 中可见 MEMSTORE_READ_ROW_COUNT 仍持续增加，SSSTORE_READ_ROW_COUNT 未见降低，读放大问题仍存在。

问题原因

MemStore 使用率未达到 free_trigger_percentage 或者 Mini SSTable 未触发 mini minor merge（minor_compact_trigger），Queuing 模式表未触发 buffer minor merge。 判断依据为查询视图 gv$merge_info（记录分区粒度的合并与转储信息）：select * from gv$merge_info where table_id=$table_id and action='buffer minor merge' order by start_time desc limit 10;。

解决方案

1. 结合业务数据变更频率及 SQL 回退情况，部署定时任务手动执行表级别转储。

   alter system minor freeze partition_id='$partition_id%$partition_cnt@table_id';
   

2. 确认 buffer minor merge 是否生效。

   
   select * from  gv$merge_info where table_id=$table_id and action='buffer minor merge' order by start_time desc limit 10;
   
   select svr_ip,sum(size/1024/1024) size_mb,count(*) from __all_virtual_table_mgr where table_type=8 and table_id=$table_id group by svr_ip order by svr_ip;
   

适用版本

OceanBase 数据库 V3.x 版本。