乐趣区

关于oceanbase:技术分享-OceanBase-里的-BUFFER-表

jiezi

作者：杨涛涛

资深数据库专家，专研 MySQL 十余年。善于 MySQL、PostgreSQL、MongoDB 等开源数据库相干的备份复原、SQL 调优、监控运维、高可用架构设计等。目前任职于爱可生，为各大运营商及银行金融企业提供 MySQL 相干技术支持、MySQL 相干课程培训等工作。

本文起源：原创投稿

* 爱可生开源社区出品，原创内容未经受权不得随便应用，转载请分割小编并注明起源。

之前在学习 OBCP 的培训资料时，有一项名为 BUFFER 表的解释，过后也没太在意（次要是 OBCP 考试里没有波及到），之后当他人考我时，我 ……！

什么是 BUFFER 表（OceanBase 里也叫 Queuing 表）？之前我认为 BUFFER 表就是全局长期表或者说是相似 MySQL 一次性整体导入的 MyISAM 表，对这类表的操作无非是划出一块内存区域对其进行读写，来防止频繁的 IO 操作。通过查阅 OceanBase 官网文档后，这个 BUFFER 表并非我了解的那样（我的了解齐全谬误）。

所谓 BUFFER 表指的是某张表（表记录数可能并不多）被频繁的全量更新（所有记录被执行批量 DML 操作）、按肯定比率更新（比方 20% 的记录被执行批量 DML 操作），短时间又对这张表进行全量检索，性能急剧下降或者说比之前性能有明显降低的这样一种景象。对于 OceanBase 来讲，对表的 DML 操作都是只打标记（比方 UPDATE，变为 DELETE 打标记 +INSERT），后盾再缓缓异步清理旧的数据。所以必然会在更新频率过快并且后盾线程清理数据不及时导致的重大读写放大问题、或者统计信息重大不精确（OceanBase 统计信息在合并时触发）导致的执行打算非最优的问题，最终影响检索性能。

能够通过如下操作来进行补救：

  1. 绑定执行打算，人为疏导优化器抉择最优执行门路。比方创立 OUTLINE 让 SQL 语句绑定固定执行打算。
  2. 手工进行转储或者合并来清理无用数据。
  3. 给表加属性 table_mode=’queuing’。这个属性是 OceanBase 专门为 BUFFER 表做的优化，具体流程简略概述为：当 BUFFER 表更新记录数超过肯定阈值时，主动对这张表进行独自转储以打消大量有效检索，从而实现对 BUFFER 表的疾速检索。这个表属性针对 MySQL 租户和 Oracle 租户都无效。Oracle 租户能够自定义 BUFFER 表转储阈值：一个是触发基于全量数据的转储百分比（_ob_queuing_fast_freeze_min_threshold）; 另外一个是触发疾速转储的记录数（_ob_queuing_fast_freeze_min_count）。MySQL 租户目前没看到对应配置项，然而其对 BUFFER 表的批量更新申请，后盾也会有对应的转储操作（对应表：gv$merge_info）。

比方在 MySQL、Oracle 租户下都创立一张表 t2，指定表 table_mode=’queuing’。

<mysql:5.6.25:ytt>create table t2 (id int primary key, r1 int,r2 varchar(100)) table_mode='queuing';
Query OK, 0 rows affected (0.032 sec)

MySQL 租户下执行上面语句：

<mysql:5.6.25:ytt>insert into t2 with recursive tmp(a,b,c) as (select 1,1,'mysql' union all select a+1,ceil(rand()*200),'actionsky' from tmp where a < 20000) select * from tmp;
Query OK, 20000 rows affected (0.916 sec)
Records: 20000  Duplicates: 0  Warnings: 0

<mysql:5.6.25:ytt>delete from t2;
Query OK, 20000 rows affected (0.056 sec)

Oracle 租户下能够执行上面语句：

<mysql:5.6.25:SYS>insert into t2 select level,100,'oracle' from dual connect by level <=20000;delete from t2;
Query OK, 20000 rows affected (0.070 sec)
Records: 20000  Duplicates: 0  Warnings: 0

Query OK, 20000 rows affected (0.088 sec)

屡次执行下面这些语句后，能够在 sys 租户下查看 MySQL 租户、Oracle 租户后盾针对表 t2 的独自转储记录：字段 action 为 buf minor merge 的行。

<mysql:5.6.25:oceanbase>SELECT *
    -> FROM 
    ->     (SELECT c.tenant_name,
    ->          a.table_name,
    ->          d.type,
    ->          d.action,
    ->          d.version,
    ->          d.start_time
    ->     FROM __all_virtual_table a
    ->     JOIN __all_virtual_meta_table b using(table_id)
    ->     JOIN __all_tenant c
    ->         ON (b.tenant_id=c.tenant_id)
    ->             AND c.tenant_name in ('mysql','oracle')
    ->     JOIN gv$merge_info d
    ->         ON d.table_id =a.table_id
    -> where d.action like 'buf minor merge' 
    ->     ORDER BY  d.start_time DESC limit 2 ) T
    -> ORDER BY  start_time asc; 
+-------------+------------+-------+-----------------+------------------+----------------------------+
| tenant_name | table_name | type  | action          | version          | start_time                 |
+-------------+------------+-------+-----------------+------------------+----------------------------+
| mysql       | t2         | minor | buf minor merge | 1678867962096191 | 2023-03-15 16:13:14.774809 |
| oracle      | T2         | minor | buf minor merge | 1678871458311991 | 2023-03-15 17:11:38.426437 |
+-------------+------------+-------+-----------------+------------------+----------------------------+
2 rows in set (0.008 sec)
退出移动版