OceanBase性能优化：最新实战指南

OceanBase性能优化：最新实战指南

随着数字化转型的加速，OceanBase作为领先的分布式数据库，其性能优化变得尤为重要。本指南详细介绍了OceanBase的多项优化策略，包括存储引擎优化、SQL优化、索引优化、内存优化等方面。通过这些实用的优化技巧，您可以大幅提升数据库的性能和稳定性，从而更好地应对各种业务挑战。快来学习这些最新的实战经验吧！

SQL性能优化是提升数据库查询效率的关键。以下是一些基本的优化方法：

1. 开启并行执行：从OceanBase 4.2版本开始，已经支持了自动并行度选择（auto dop）。如果用户不熟悉并行度的设置规则，可以设置parallel_degree_policy为AUTO，让优化器自动选择合适的并行度。

2. 创建合适索引：索引可以显著提高查询速度。具体方法将在“索引优化”部分详细讨论。

3. 调整连接方式：通过优化表的连接顺序，可以提升查询效率。例如，如果有三个表t1、t2和t3进行连接，可能需要尝试不同的连接顺序以找到最优方案。

4. 调整连接顺序：在复杂查询中，通过使用hint来指导优化器选择正确的连接顺序，可以有效提升性能。

5. 检查查询改写：确保数据库进行了正确的查询改写，避免因错误的改写导致性能下降。

分析性能瓶颈的步骤

1. 利用SQL执行计划：通过分析执行计划，可以定位哪些步骤（算子）的执行时间较长。一个实用的方法是将大SQL拆分成小SQL进行分析。

2. 使用监控工具：充分利用系统提供的监控视图，如oceanbase.GV$SQL_PLAN_MONITOR，来简化分析过程。

实战案例

考虑以下SQL查询：

SELECT *
FROM bbtr
JOIN cte ON bbtr.id = cte.id
JOIN btr ON bbtr.id = btr.id;

执行计划显示：

=============================
|ID|OPERATOR           |NAME|
-----------------------------
|4 |NESTED-LOOP JOIN   |    |
|5 |├─MERGE JOIN       |    |
|6 |│  └─TABLE SCAN    |BBTR|
|7 |│  └─TABLE SCAN    |CTE |
|8 |└─TABLE GET        |BTR |
=============================

从执行计划中可以看出，bbtr表与cte表的merge join是性能瓶颈。通过检查每个表的数据量和过滤条件，发现cte表在过滤后返回1638行，但扫描耗时异常高达2.13秒。这表明在该步骤存在明显的性能问题，需要进一步优化。

在OceanBase 4.3版本中，新增了列存储引擎支持，实现了存储一体化。这一特性能够同时兼顾TP（事务处理）和AP（分析处理）类查询的性能。

列存储引擎的优势

列存技术显著提升了分析类查询的效率，这是OceanBase实现HTAP（混合事务/分析处理）的关键特性。对于OLAP场景，列存组织下的数据更静态，适合批量写入和较少的随机更新。

整体架构

OceanBase采用分布式架构，用户数据默认多副本存储。每个用户数据分为基线数据和增量数据两大部分：

• 基线数据：通过定期的Major Compaction生成，所有副本的基线数据物理上完全一致。

• 增量数据：包含用户在最新版本基线数据之后的所有写入数据，各个副本独立维护。

OceanBase的列存实现方式具有以下特点：

• 基线数据存储为列存模式，增量数据保持行存。这种设计使得用户的所有DML操作不受影响，同时能够享受列存带来的性能优势。

• 每列数据存储为独立的SSTable，所有列的SSTable组合成虚拟SSTable作为用户的列存基线数据。

• 根据用户需求，基线数据可以设置为行存、列存或行列冗余三种模式。

SQL和存储一体化

为了更好地支持OLAP需求，OceanBase在多个层面进行了优化：

• SQL一体化：实现了新的代价模型和向量化引擎，能够根据数据表存储模式自动选择最优执行计划。

• 存储一体化：用户可以根据业务负载类型灵活设置数据存储模式，同时支持所有在线及离线DDL操作和数据类型。

索引是提升数据库查询性能的重要手段。在OceanBase中，创建合适的索引可以显著减少数据扫描量，消除排序等操作。

OceanBase索引基础知识

在OceanBase中，索引除了包含索引键外，还会包含主表的主键。这是因为需要通过主表的主键来关联索引中的行与主表中的行。因此，索引表中需要包含主表的主键以实现反向查找。

例如，创建一个名为idx_b的索引：

CREATE TABLE test(a INT PRIMARY KEY, b INT, c INT, KEY idx_b(b));

查询该索引的列信息：

SELECT
  column_id,
  column_name,
  rowkey_position,
  index_position
FROM
  oceanbase.__all_column
WHERE
  table_id = (
    SELECT
      table_id
    FROM
      oceanbase.__all_table
    WHERE
      data_table_id = (
        SELECT
          table_id
        FROM
          oceanbase.__all_table
        WHERE
          table_name = 'test'
      )
  );

结果显示，虽然索引创建在b列上，但还包含了主表的主键列a。

创建合适索引的策略

1. 选择合适的列：根据查询条件和过滤效果选择索引列。通常选择过滤性好的列作为前导列。

2. 考虑索引顺序：索引列的顺序会影响查询性能。将选择性高的列放在前面。

3. 避免过度索引：过多的索引会增加写入成本和存储开销。需要权衡读写性能。

实战案例

假设有一个查询：

SELECT *
FROM orders
WHERE order_date >= '2024-01-01' AND customer_id = 123;

为了优化这个查询，可以创建一个复合索引：

CREATE INDEX idx_order ON orders(order_date, customer_id);

执行内存占用高是OceanBase应用中常见的问题，特别是在小规格场景下可能导致整个租户无内存可用。以下是一些诊断和解决方法：

获取内存占用高的代码堆栈

在OceanBase V2.x和V3.x版本中，可以通过以下步骤获取内存占用高的代码堆栈：

1. 在SYS租户中打开mem_leak监控：

   ALTER SYSTEM SET leak_mod_to_check='OB_COMMON_ARRAY';
   

2. 等待一段时间后，查询泄露堆栈：

   SELECT * FROM oceanbase.__all_virtual_mem_leak_checker_info ORDER BY alloc_count DESC;
   

3. 使用addr2line工具解析堆栈：

   addr2line -pCfe /home/admin/oceanbase/bin/observer xxxxx
   

在V4.0及以上版本中，可以通过GV$OB_MEMORY视图获取占用内存较高的模块，并通过__all_virtual_malloc_sample_info视图获取具体的backtrace信息。

具体问题场景及解决方案

1. SqlExecContext模块问题：在repeat、space等表达式向量化场景下，该模块内存可能膨胀到10GB以上。这个问题在V4.2版本得到缓解，V4.3版本彻底解决。

2. multi table replace算子模块：在某些场景下，SQL_EXEC_CTX_ID内存可能膨胀至190GB。需要通过优化查询和数据处理方式来避免。

通过以上方法，可以有效地诊断和解决OceanBase应用中的内存占用问题，提升系统整体性能和稳定性。