前言：使用 Benchmark 工具进行测试是一个探索数据库性能的好方法，然而由于大家对 OceanBase 的架构或者特性还不够熟悉，经常会发现使用 Benchmark 工具跑出来的性能数据并不符合预期。本篇文档以此为锲机为大家介绍「影响 Benchmark 性能的 OceanBase 常见操作和场景」，希望能对各位在 Benchmark 测试中提供参考。
一、转储合并
1、转储操作
转储是租户级别的，当一台服务器中一个租户 MemTable 的内存占用超过租户内存上限的一定比例时，就会触发小版本冻结（Minor Freeze）。所谓冻结，就是禁止当前活跃 MemTable 的写入，并同时创建新的空 MemTable 以支持新的写入。被冻结后的 MemTable 就成为一个静态的数据结构，可以被后台线程读取并转储为 SSTable。
2、合并操作
合并是全局级别的，合并会把当前大版本的 SSTable 和 MemTable 与前一个大版本的全量静态数据进行合并，产生新的全量数据，合并操作包含转储操作。
3、对性能的影响
- 合并转储简单说就是把内存数据刷到磁盘上，存储层统计信息可以更准确，生成的执行计划更优更稳定。
- MemTable SCAN 性能差，合并后 Range 查询会更优。
4、受影响的场景
- 对 TPCH、BMSQL 来说
一般来说 TPC-H、BMSQL 数据量较大，导完数据后大概率会触发转储，此时做合并会有积极影响。
影响分两个方面：
1、Major 合并会将基线 SSTable 与之后转储的增量 SSTable 合并为一个 SSTable，减少跨 SSTable 的查询，提升查询效率 ；
2、同时更新统计信息，使执行计划更稳定。
- 对 Sysbench 来说
Sysbench 一般数据量较小，导完数据后尽量不要发生转储，此时做合并有消极影响。
影响在于：合并转储将 MemTable 刷到硬盘，多了一个 Major SSTable ，从硬盘操作数据肯定比在 MemTable 要慢（ MemTable SCAN 是另外一种情况，不在本文做讨论。），导致性能下降。
二、DATA PATH 分布
1、单盘部署的风险（CLOG、LOG、DATA 目录均在一块盘）
1.CLOG 80% 水位线，超过 95% 集群会停写；
2.转储合并时消耗额外的 IO，CPU ，部署在一块盘上性能无法保证；
3.LOG 打太多、 IO 高时可能会导致无主；
4.LOG 打满可能会导致集群不 work；
5.影响 liboblog 同步，可能很容易导致 CLOG 回收，或者同步历史数据慢；
2、解决方案
1、CLOG 、LOG、DATA 目录 分盘部署/lvm 逻辑分区，减少 I/O 抢占；
2、开启日志限流功能（每秒最多打多少日志）alter system set syslog_io_bandwidth_limit='5 M'；
3、开启日志自动回收，日志存活数 enable_syslog_recycle: true max_syslog_file_count: 4；
4、CLOG 已有的配置项 clog_disk_usage_limit_percentage 95% 停写水位线 ；clog_disk_utilization_threshold 80% 回收水位线，用于控制 CLOG 或 ILOG 磁盘空间复用的水位值。
三、Primary Zone分布
对于性能测试来说，建议 Primary Zone 设置为 RANDOM，这样可以尽可能的利用所有的 OBServer 。如果设置 Primary Zone=Zone1 ，那么所有的读写操作都会集中到 Zone1 上，很容易成为性能瓶颈，测试的是类似单机的性能 。
四、Table_group 和 pg
1、Table_group 的作用
Table_group 是一个逻辑概念，它和物理数据文件没有关联关系，Table_group 只影响表分区的调度方法，OceanBase 数据库会优先把属于同一个 Table_group 相同分区号的分区，调度到同一台节点上，以减少跨节点分布式事务。
2、受影响的场景：
- BMSQL、TPCH
Table_group 和 pg 有积极影响；
BMSQL 和 TPCH 都是大数据量涉及多表的 SQL，此时应用 Table_group 可以将查询涉及的表分区做整合，减少跨节点分布式事务，提升性能。
- Sysbench
Table_group 无影响；
OLTP CASE 里面，不同 SQL 访问的 Table、ID 不一样，且只针对单张表，Table_group 则无作用。
结论：
在 BMSQL 的测试模型中，几乎所有的表都和 w_id 这一列字段强相关，也就是表之间都有关联关系，所以使用 Table_group 提升巨大 。
在 Sysbench 的测试模型中，所有表都是单表访问，Table_group 没有影响 。
在 TPCH 的测试模型中， lineitem/orders/part/partsupp 这几张表有关联关系，使用 Table_group 有一定的性能提升。
五、分区表使用场景
1、分区表的作用
使用分区表可以将表数据按照分区键和分区方式进行切割，分为一个个的 Partition 存储；在单机的存储和计算能力不足以支撑单张物理表，物理表需要拆分成多个Partition。
2、受影响的场景
TPCH、BMSQL
1、对 TPCH 和 BMSQL 有积极影响，因为这种场景下通常单表数据量比较大；单表数据打散可以提升分布式性能（一张表的 leader 打散到多台机器，不会有热点问题）。
2、为了防止分区表全局索引性能问题，BMSQL 和 TPCH 都创建 local 索引。
对 Sysbench 的影响主要在两点：
1、Range 分区查询时，会增加分布式查询的开销，对性能有消极影响。
2、Sysbench 默认创建全局索引，UPDATE 全局索引会涉及分区（本例用 Hash 分区），几乎所有 Partition，会对性能有消极影响。
结论：
point_select：点查只涉及单分区，没有跨分区的事务，对性能没有影响。
RO_Range：Rang 分区查询，会跨区，有分布式查询开销，性能会下降且实际影响很大。
INDEX：UPDATE sbtest%u SET k=k+1 WHERE id=? 涉及分区表全局索引的修改，性能会下降。
BMSQL、TPCH 使用分区表性能均能有提升
六、全局索引和本地索引使用场景
1、全局索引和本地索引的作用
- 本地索引
分区表的本地索引和非分区表的本地索引类似，索引的数据结构和主表的数据结构保持一对一的对应关系，但由于主表已经做了分区，主表的“每一个分区”都会有自己单独的索引数据结构。对每一个索引数据结构来说：里面的键（Key）只映射到自己分区中的主表数据，不会映射到其它分区中的主表，因此这种索引被称为本地索引。本地索引的分区方式和分区键与主表相同，但无法做到全局唯一性约束。
- 全局索引
和分区表的本地索引相比，分区表的全局索引不再和主表的分区保持一对一的关系，而是将所有主表分区的数据合成一个整体来看，索引中的一个键可能会映射到多个主表分区中的数据（当索引键有重复值时）。更进一步，全局索引可以定义自己独立的数据分布模式，既可以选择非分区模式也可以选择分区模式；在分区模式中，分区的方式既可以和主表相同也可以和主表不同。全局索引可以有非分区和分区模式，分区也可以是独立的分区方式和分区键。
全局索引非必要不要随便用；一般都是有全局唯一的需求，或者是能明确通过全局索引能提升用户场景请求的性能。
2、受影响的场景
分区表场景
- 分区表的全局索引对性能的影响：
缺点：对修改操作的影响很大，一个简单的 DML 语句都会因为要同步修改全局索引而产生分布式事务，影响性能。
优点：可以做到全局唯一性约束，某些业务兼容性更友好。
- 分区表的本地索引对性能的影响：
优点：只对对应的 Partition 进行索引。不会涉及全局的修改；仅是本地事务，对性能相对友好。
缺点：缺少全局唯一性约束。
非分区表场景
非分区表的全局索引在 SCHEMA 上是全局索引，但是实际存储和 local 索引是一样的；也可以理解为：非分区表没有全局索引的说法。
结论：
在非分区表场景，全局索引和 LOCAL 索引对性能的影响没有区别。
在分区表场景，全局索引涉及全局的 DML 修改，对性能有消极影响。
一般来说，Sysbench 、TPCH、BMSQL均建议使用本地索引。
————————————————————————————————————————————
社区版官网论坛
社区版项目网站提 Issue
欢迎持续关注 OceanBase 技术社区，我们将不断输出技术干货内容，与千万技术人共同成长！！！
搜索🔍钉钉群，或扫描下方二维码，还可进入 OceanBase 技术答疑群，有任何技术问题在里面都能找到答案哦～
