OceanBase慢查询问题(Buffer表案例)

转自：DBA阿Q

OB3.2.4.8的集群出现了慢查询告警，一条简单的SQL语句，执行时间达到1秒多。

1.首先排查慢SQL是否缺失索引或走错了执行计划

查询条件add_time字段有索引，执行计划是反向扫描的索引回表查询，符合预期

SELECTid,file_size,file_name,md5,store_path,add_time FROM table1 WHERE (add_time <= ‘2026-03-05’) ORDER BY add_time DESC limit 100;

2.SQL诊断页面查看SQL采样的数据，内存读行数和Sstore读行数较高

3.SQL运行趋势显示这句SQL的执行时间是逐步增长的

4.审计视图中查询这张表的访问，发现有较多的INSERT和DELETE操作，开发反馈业务上确实新增了大量写入删除逻辑，OB4.x版本新增了DBA_TAB_MODIFICATIONS 视图，可以更方便的观察表的增删改次数

5.判断这张表现在的访问符合Buffer表特征，修改这张表的TABLE_MODE为queuing

ALTER TABLE table1 TABLE_MODE = ‘queuing’;

6.查询转储记录，16:10进行了buffer minor merge转储调度，这是对 queuing表的特殊转储机制

select * from oceanbase.gv$merge_info where TABLE_ID=1112705767359335 order by START_TIME desc limit 10;

7.buffer minor merge转储后，慢查询的执行时间大幅下降

8.Queuing表转储机制

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

想了解更多干货，可通过下方扫码关注