OceanBase SQL性能分析方法

---

1、OceanBase SQL执行流程

1.1 执行计划

1.2 基表计划

1.3 索引选择

• 索引（目前只有B-tree索引）
  • create table test(a int primary key, b int, c int, key idx_b(b));
  • 索引键会自动补上主键, 为了回表，Oracle使用物理Rowid回表
  • 无主键表，Oceanbase内部会有自增ID
• 索引的三个优势
  • 快速定位(根据索引列条件), 减少数据扫描
  • 索引列是有序的, 消除排序
  • 索引一般比主表小(引入的问题是回表，其实这是劣势)
  • OceanBase主表本身也可以看做是索引
• 快速定位(query range): 减少数据扫描量
  • Query range: 用来定位扫描开始和结束的位置

create table test(a int primary key, b int, c int, d int, key idx_b_c(b,c));
explain extended select/*+index(test idx_b_c)*/ * from test where b = 1;
explain extended select/*+index(test idx_b_c)*/ * from test where b > 1;
explain extended select/*+index(test idx_b_c)*/ * from test where b = 1 and c > 1;
explain extended select/*+index(test idx_b_c)*/ * from test where b > 1 and c > 1 ;
explain extended select/*+index(test idx_b_c)*/ * from test where b >= 1 and c > 1 ;

• 索引列有序: 消除排序
  
• 索引:一般比主表小
• 比主表小优势: 减少数据扫描量
  • explain select count(*) from t1
  • 选择列数最少的索引(数据量最小的索引)
• 比主表小劣势: 可能需要回表
  

1.4 如何衡量一个索引的执行时间

• 索引的执行时间

  • 扫描索引的时间(由扫描的数据行数决定, i.e. query range)
  • 索引回表的时间(由需要回表的数据行数决定)
  • 假设基表有1w行数据
    • b=1(1k), b = 1 and c = 1(100行), b = 1 and d = 1(100行)

• 线上环境如何获取这些信息: 执行select count(*)

1.5 连接路径和连接算法

• 连接算法

2、常用的SQL性能定位和优化方法

2.1 Oceanbase.gv$sql_audit

• 记录了sql每次执行的状态信息
• 需要了解sql audit中记录的每一个字段的含义
  • retry_cnt: 太多基本上就是锁冲突
  • queue time: 很高表明CPU资源不够用
• 可以关闭sql audit 供当前分析
  • alter system set enable_sql_audit = false;

2.2 分析关闭之后的Sql Audit

2.3 gv$plan_cache_plan_stat

• 记录了每个计划的信息
• 每日合并会触发计划淘汰，这个表会被更新
• 可以通过该表找到Top-SQL

2.4 gv$plan_cache_plan_explain

• 记录了具体的计划信息
• 需要提供四元组(tenant_id, ip, port, plan_id)

2.5 Explain和plan-cache-plan-explain关系

• Explain不走plan-cache,使用最新的统计信息生成计划
• Plan-cache-plan-explain缓存的是第一次优化给SQL时候生成的计划
• 对于同一条SQL，Explain和Plan-cache-plan-explain的计划可能是不一样
  • 生成计划的时候的统计信息不一致
  • 生成计划的时候表的分布可能不一致
• 分析慢查询的时候，以plan-cache-plan-explain的为准