OceanBase开发规范和最佳实践

开发使用的注意点

1.分区表的使用建议

1. 业务形态（热点数据打散、历史数据维护便利性、业务SQL的条件形态（分区裁剪））。
2. OB各种分区类型的设置要求。
3. 大表变分区表。
4. 分区键的选择，分区键必须是主键的子集。
5. 考虑分区裁剪、partition wise join优化。
6. Range分区，最后一个不能是maxvalue。
7. 分布式事务，Leader Binding、Table Group。
8. 为了避免写入放大问题，选择表的自定义主键时，不要使用随机生成的值，要尽量有序，比如时序递增的。
9. 分区个数：单机分区上限（5万）、单机租户允许创建的最大分区数量上限（租户内存）、单表分区数上限（8192）。

2.局部索引和全局索引的取舍

1. 如果查询条件里“包含完整的分区键”，使用本地索引是最高效的（分区裁剪）。
2. 如果需要“不包含完整分区键”的唯一约束，1）使用全局索引；2）使用本地索引，且需要索引列上必须带上表的分区键。
3. 其他情况，
   • 通常来说，全局索引能为高频且精准命中的查询（比如单记录查询）提速并减少IO；对范围查询则不一定哪种索引效果好。
   • 不能忽视全局索引在DML语句中引入的额外开销：数据更新时带来的跨机分布式事务，事务的数据量越大则分布式事务越复杂。
4. 如果数据量较大，或者容易出现索引热点，可以考虑创建全局分区索引。

3.分布式事务流程及优化方法

1. 2PC流程用户感知的commit延迟
   • 标准：4次日志延迟 + 2次RPC延迟
   • OB：1次日志延迟 + 2次RPC延迟
2. 优化办法：
   • 尽量避免跨机分布式事务。
   • 慎重选择事务中的第一条语句，因为OBProxy的路由规则。
   • Primary_zone、Table Group设置。

4.OB Proxy的路由规则

1. proxy parser 在根据SQL选择server时，有以下几点特殊的逻辑：
   • proxy parser只解析Begin/START TRANSACTION/SET 和其他DML语句，如果遇到其他单词开头的语句，proxy的parser会直接跳过，认为该语句不包含表名。
   • proxy parser会按照第一条包含实体表名的stmtement进行路由，如果整个stmtement都不包含表名，则将请求发送至上一条SQL所发送的server。
2. OB Server会根据执行计划的类型，来告诉proxy是否将请求路由至正确的server，如果路由失败，proxy会更新location，当前的反馈机制如下：
   • server返回第一条DML的命中情况
3. 推荐用法：

3.1 以下几种情况（select可以等价替换成update/delete/replace/insert，下同），proxy能够将请求发送至正确的server，并且server能够按照proxy的命中情况进行反馈。

begin; select * from t1; commit;

set @@autocommit = 1; insert into t1 values(); set @@autocommit = 0；

select * from t1; insert into t2 values();

set @@ob_trx_timeout = 10000000; begin; select * from t1; commit;

3.2 以下几种情况，proxy会将请求发送至上一个SQL所使用的server。

create table t1(id int primary key);create table t2(id int primary key);

4. 不推荐用法：

4.1 以下几种情况（第一个DML是非实体表），proxy能够将请求发送至正确的server，但是server反馈的信息可能不准，不建议使用。

select '1'; select * from t1;

select '1' from dual; select * from t1;

4.2 以下几种情况，proxy可能能够将请求路由至正确的server，但是server反馈的信息可能不准确，不建议使用。

create table t1(id int primary key); insert into t1 values();

4.3 以下几种情况，proxy会强制将请求路由至上一次使用的server，server反馈的信息可能不准确，不建议使用。

show warnings; select * from t1;

show count(\*) errors; select * from t1;

5.大事务尺寸限制、长事务

【报错】

• ERROR 6244(HY000): out of transaction threshold

【原因】

• LSMT结构，批量写出脏数据。
• 冻结动作时不能“转储未提交事务”，需要事务搬迁到1-freeze_trigger%

【场景】

• 业务租户内存配置较低
• 单体大事务
• 事务并发量大

【建议】

• 调整具体的表结构和调整业务的并发量
• 数据生命周期管理，考虑partition add/drop，而不是delete
• 调整业务SQL逻辑，将大段的事务拆成小段

6.悬挂、长事务和超时保护机制

【概念】

• 悬挂事务
• 长事务

【危害】

• 持有memtablede的ref，memstore内存爆炸

【建议】

1. 谨慎的timeout设置
   • 查询超时系统变量：ob_query_timeout（默认10s）
   • 事务超时参数：ob_trx_timeout（默认100s）
   • 事务空闲超时：ob_trx_idle_timeout（默认120s）
2. 事务及时提交

【监控】

select * from _all_virtual_trans_stat where (now() - ctx_create_time) > 1000;

7.Buffer表的使用建议

【业务形态】

• 会在短时间内 写入-修改-删除

【问题】

• fuse流程时 data scan 时链路变长，SQL变慢

【原因】

• LSTM的变更链路

【常见的Mitigation】

• OB：memtable row purge
• OB：针对buffer表使用特殊的转储策略：fast freeze
• 手工major freeze以消除多版本，减少层级
• CBO统计信息不准确导致的sql plan change、outline绑定

8.适配大查询隔离参数

【为什么要适配】

• 每个租户分配一定比例的资源来处理大查询

【对应参数】

• large_query_threshold(default 100ms)
• large_query_worker_percentage(30)

【适配点】

• 这些参数需要精细化控制。
• 这是因为 租户级的活跃线程数是一个容量资源，线程数量是固定的。

9.业务幂等重试逻辑

【报错】

• -6225: ERROR 4012(25000):OB-4012:Transaction result is unknown
• Communication link failure during commit().Transaction resolution unknown.

【场景】

• 切主时的事务搬迁
• 网络RPC队列堆积、网络传输慢
• 2PC过程中协调者宕机
• 事务超时参数 ob_trx_timeout （默认100s）/ob_trx_idle_timeout（默认120s）

【建议】

• 业务适配幂等重试逻辑
• 监控

10.定时合并任务、Noisy Neighbor问题

1. 合并任务都做了什么？
   • Compaction
   • 数据压缩
   • 数据校验
   • 渐进schema变更
   • 统计信息收集
2. 定时合并任务默认时间为 02:00
3. Noisy Neighbor问题

11.自增列、无主键表、Sequence

1. 自增列

   • 可以指定自增起始值、自增步长、自增列缓存大小

   • MySQL mode:

     create table `test`(
     `id` int(32) not null auto_increment comment '自增id',
     ……)

   • 连续性：跳变问题

2. 无主键表

   • 基于自增列方式生成的隐藏列
   • sync_value同步调优by autoinc_cache_refresh_interval
   • 建议建表时为表设计主键或者唯一键
   • 不支持后加主键

3. Sequence

   • 默认使用 cache + noorder ，性能考虑
   • Cache Size：单机TPS=100时候，cache size 建议100*60*60=360000