Buffer 表

Buffer 表表示频繁插入删除的表，这里的“表”也包括索引表（主表上更新索引列，体现在索引表上就是删除和插入动作）。Buffer 表问题是基于 LSM-Tree 机制实现的存储引擎的通用问题。LSM-Tree 架构下的存储引擎，数据分为基线数据和增量数据，增量数据主要存在于内存 MemTable 中，并通过转储写到磁盘的转储 SSTable，每日合并时写到磁盘上的基线 SSTable，查询时需要合并 MemTable、转储 SSTable、基线 SSTable 三者的数据从而生成最终数据。该架构下被删除的数据是标记删除，在每日合并前不会物理生效。当增量数据中积累了大量标记删除的数据时，从上层应用视角实际存在的行很少，但范围查询时可能需要处理较多的标记删除的数据，从而导致 SQL 耗时不够理想。同时 Buffer 表场景下也容易导致优化器生成非最优执行计划。

通过以上分析，可以总结 Buffer 表具有如下特征：

• 触发条件：

  表中数据频繁大比例更新。

• 产生场景：

  • 应用逻辑有大量的插入、删除操作。

  • 应用逻辑有大量的索引列更新。

• 直接现象：

  表行数不大，但查询很慢。

• 问题原因：

  • 标记删除的数据导致范围查询时处理数据量增多。

  • 执行计划非最优。

当通过 V$OB_SQL_AUDIT 视图判断为 SQL 问题时，如果疑点 SQL 具备范围查询的特征，可以进一步确认该表是否为 Buffer 表。

Buffer 表检测逻辑

可以通过内部视图统计表级别的总行数和插入、更新、删除的行数增量，当满足以下任意条件时，可以判定为 Buffer 表：

• 主表同时存在大量的插入和删除：插入行数增量和删除行数增量相近，且插入和删除的行数较多。

• 大量更新索引列，更新行数增量占总行数比例较大，且更新行数较多。

对于该问题，可以通过以下方式解决：

• 分析是否有更优的执行计划，并通过 CREATE OUTLINE 语句手动绑定。

• 手动触发合并，从而将标记删除的数据物理删除。

如无更优的执行计划，需要通过合并解决，但需要尽快恢复，可以尝试如下手段：

• 扩容

• 调大系统参数 cpu_quota_concurrency

  cpu_quota_concurrency 用于设置租户的每个 CPU 配额所允许的最大并发数。详细信息，参见 cpu_quota_concurrency

• 对问题 SQL 限流（尽可能小的流量，甚至限停）