如何从运维的角度找到需要转换为Queuing的表？从哪里可以看出扫描大量包含删除标记的数据，有相关的等待事件或者执行计划中是否可以体现出查询变慢？
官档原文如下：
在 LSM Tree 架构下，对数据行的删除并不是原地删除，而是通过写入一行 Delete 操作（tombstore）来标记删除，如果某个用户业务表主要操作为频繁的插入与删除，从绝对数据量上来看可能并不大，但是由于 LSM Tree 的架构特征，会导致对这类表的增量数据中存在大量的 Delete 标记, 即使用户的实际扫描范围很小，但是 SSTable 内部无法快速识别这些数据是否删除，仍然要扫描大量包含删除标记的数据，导致一个小查询的响应时间可能远远超过用户预期。为了解决这类表的查询性能问题，OceanBase 数据库为用户特别提供了一种支持自定义的表模式，称为 Queuing 表 （从业务角度有时候也会称为 Buffer 表 ），对其实现了特殊的转储策略。可以通过如下方式指定 queuing 表模式。
对于 queuing 表具体来说，OceanBase 数据库引入一种自适应的 buffer 表转储策略，由存储层在每次转储时根据转储的统计信息来自主判断是否需要对该表采用 buffer 表转储策略，当发现一个表存在类似 buffer 表行为时，接下来会尝试对这个表做 buffer minor merge 的调度，对这个表基于 Major SSTable 和最新的增量数据以当前的读快照时间生成一个 Buf Minor SSTable，这次 Compaction 动作会消除掉增量数据里的所有 Delete 标记，后续查询基于新生成的 Buf Minor SSTable 就可以避免原有的大量无效扫描动作。
