开发使用的注意点
1.分区表的使用建议
- 业务形态（热点数据打散、历史数据维护便利性、业务SQL的条件形态（分区裁剪））。
- OB各种分区类型的设置要求。
- 大表变分区表。
- 分区键的选择，分区键必须是主键的子集。
- 考虑分区裁剪、partition wise join优化。
- Range分区，最后一个不能是maxvalue。
- 分布式事务，Leader Binding、Table Group。
- 为了避免写入放大问题，选择表的自定义主键时，不要使用随机生成的值，要尽量有序，比如时序递增的。
- 分区个数：单机分区上限（5万）、单机租户允许创建的最大分区数量上限（租户内存）、单表分区数上限（8192）。
2.局部索引和全局索引的取舍
- 如果查询条件里“包含完整的分区键”，使用本地索引是最高效的（分区裁剪）。
- 如果需要“不包含完整分区键”的唯一约束，1）使用全局索引；2）使用本地索引，且需要索引列上必须带上表的分区键。
- 其他情况，
- 通常来说，全局索引能为高频且精准命中的查询（比如单记录查询）提速并减少IO；对范围查询则不一定哪种索引效果好。
- 不能忽视全局索引在DML语句中引入的额外开销：数据更新时带来的跨机分布式事务，事务的数据量越大则分布式事务越复杂。
- 如果数据量较大，或者容易出现索引热点，可以考虑创建全局分区索引。
3.分布式事务流程及优化方法
- 2PC流程用户感知的commit延迟
- 标准：4次日志延迟 + 2次RPC延迟
- OB：1次日志延迟 + 2次RPC延迟
- 优化办法：
- 尽量避免跨机分布式事务。
- 慎重选择事务中的第一条语句，因为OBProxy的路由规则。
- Primary_zone、Table Group设置。
4.OB Proxy的路由规则
- proxy parser 在根据SQL选择server时，有以下几点特殊的逻辑：
- proxy parser只解析Begin/START TRANSACTION/SET 和其他DML语句，如果遇到其他单词开头的语句，proxy的parser会直接跳过，认为该语句不包含表名。
- proxy parser会按照第一条包含实体表名的stmtement进行路由，如果整个stmtement都不包含表名，则将请求发送至上一条SQL所发送的server。
- OB Server会根据执行计划的类型，来告诉proxy是否将请求路由至正确的server，如果路由失败，proxy会更新location，当前的反馈机制如下：
- server返回第一条DML的命中情况
- 推荐用法：
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.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内存爆炸
【建议】
- 谨慎的timeout设置
- 查询超时系统变量：ob_query_timeout（默认10s）
- 事务超时参数：ob_trx_timeout（默认100s）
- 事务空闲超时：ob_trx_idle_timeout（默认120s）
- 事务及时提交
【监控】
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问题
- 合并任务都做了什么？
- Compaction
- 数据压缩
- 数据校验
- 渐进schema变更
- 统计信息收集
- 定时合并任务默认时间为 02:00
- Noisy Neighbor问题
11.自增列、无主键表、Sequence
- 自增列
- 可以指定自增起始值、自增步长、自增列缓存大小
- MySQL mode:
create table `test`( `id` int(32) not null auto_increment comment '自增id', ……) - 连续性：跳变问题
- 无主键表
- 基于自增列方式生成的隐藏列
- sync_value同步调优by autoinc_cache_refresh_interval
- 建议建表时为表设计主键或者唯一键
- 不支持后加主键
- Sequence
- 默认使用 cache + noorder ，性能考虑
- Cache Size：单机TPS=100时候，cache size 建议
100*60*60=360000
