在 OceanBase 数据库中， “Queuing”表指在应用程序或特定业务场景中用于实现队列功能的表。这类表通常用于存储需要按顺序处理的数据记录，比如订单处理、消息传递等场景。在实际应用中，这样的表可能会被称为“Queuing”表或buffer 表类似的名称。如在短时时间内频繁的insert又批量删除或者大量更新，因为 OB 更新的本质也是 delete+insert ），如同流水表，一张表查询当前记录可能只有几千行数据，但实际上可能已经发生了百万或更多的插入和删除操作。因为OB是LSM Tree分级存储，默认设置下，一张表中删除的行在 OB 每日合并前并不是真的删除，而只是在内存里打了个删除标记，OB major freeze/merge期间才会真正删除清理标记。而频繁的堆积”mark for delete”记录，使之前的一些如全表扫描的执行计划会出现逐渐变慢问题，或错误的统计信息变为全表扫,影响SQL执行效率。如同在PostgreSQL中的表膨胀。

分析思路
# 查找SQL ID

select * from gv$sql where sql_text like '% KEY %'\G

# 查看SQL执行情况

select * from gv$sql_audit where sql_id='xxxxxxxxxxxxxxxxxxxxxx'\G

重点关注指标：EXECUTE_TIME、return_rows、MEMSTORE_READ_ROW_COUNT、SSSTORE_READ_ROW_COUNT、DATA_BLOCK_READ_CNT、DATA_BLOCK_CACHE_HIT

# 查看执行计划

 explain extended select xxxx

重点关注指标: EST. ROWS \ physical_range_rows

应急处理方案

1, 如SQL可适用索引，固定执行计划使用合适索引，如果无索引创建对应的索引
2，SQL无有效过滤条件，无法使用索引，可考虑手动触发合并，清理daed记录；
3，修改表模式table_mode 为“queuing”，自适应的buffer minor merge，更加频繁消除掉增量数据里的所有Delete标记记录, 有参数_ob_queuing_fast_freeze_min_threshold(default 10 [means > 10% rows deleted ] )和_ob_queuing_fast_freeze_min_count（default 500000 [means > 50w rows deleted]）控制，手动修改表为queuing模式的命令如下:

ALTER TABLE user_table TABLE_MODE = 'queuing';

4, SQL限流

扩展<如何查看ocenabase的冻结、转储、合并?>

查找“queuing”特征表

select a.tenant_id,a.table_id,a.partition_id,a.row_count,b.insert_row_count,b.delete_row_count,b.update_row_count 
from __all_virtual_meta_table a,__all_virtual_partition_audit b 
where a.tenant_id=b.tenant_id and a.table_id=b.table_id and a.partition_id=b.partition_id 
and b.tenant_id>1000 
and b.delete_row_count >100000 -- filter small table 
and (delete_row_count/insert_row_count>0.1 or update_row_count /insert_row_count>0.1)
and a.row_count/b.insert_row_count<0.1
order by delete_row_count/row_count desc
limit 10;

检查“queuing”merge记录

select * from gv$merge_info where table_id=xxxx;

查找QUEUING属性表

select a.tenant_id,
       b.tenant_name,
       c.database_name schema_name,
       a.table_name
  from __all_virtual_table a, __all_tenant b, __all_virtual_database c
 where a.table_type = 3  --- 0:SYSTEM_TABLE;1：SYSTEM_VIEW;2：VIRTUAL_TABLE; 3：USER_TABLE ;4：USER_VIEW; 5：USER_INDEX ;6：TMP_TABL for MySQL model
   and a.table_mode = 257    ---  256:NORMAL   257:QUEUING
   and a.tenant_id = b.tenant_id
   and a.tenant_id = c.tenant_id
   and a.database_id = c.database_id;

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

References
https://www.oceanbase.com/docs/enterprise-oceanbase-database-cn-10000000000945692

如何分析Oceanbase中频繁增删表(Queuing表)查询慢问题