Oceanbase 和 TiDB 粗浅对比之 – 执行计划

一、前言

OceanBase和TiDB作为国内2款的比较流行的兼容MySQL协议的开源数据库运用者也越来越多，两种数据库不仅在架构原理上有较大差异，在开源方法上有较大的不同：

TiDB 选用的Apache License 2.0开源协议，其榜首行代码提交就是在github上，和企业版比较社区版只是不包括拜访白名单和审计2个插件功用，其他与企业版彻底相同且同步发版(之前闭源的tiflash也于2022.4.1彻底开源)。

OceanBase社区版选用国内的木兰公共协议 MulanPubL-2.0开源，官方区分成社区版、云服务版、企业版三种类型，开源的社区版与企业版比较存在较多功用缺失或功用降低(如现在比照版本不支撑oracle兼容、不支撑闪回、不支撑analyze句子、ocp不支撑备份功用等)，且社区版本版发布与企业版不同步。另外ob的文档和资源比较较tidb还不行完善和丰厚。

本文针对tidb、oceanbase在履行方案的相关内容进行浅显的比照，也对学习做个总结，比照版本为OceanBase3.1.2-CE(2022-03-29发版)、TiDB v5.2.3(2021-12-31发版)

二、检查履行方案

• TiDB：

(1) explain SQL方法：该方法只是展现或许的履行方案并非实践的履行方案，现在各数据库都存在此问题运用explain方法并不是真正SQL履行时的方案，少数状况下会存在不共同。

(2) explain analyze方法：该方法会真正履行SQL并展现履行时的履行方案，履行方案中添加实践的履行信息包括实践回来行数、各算子时刻和调用及资源耗费等。

(3) select tidb_decode_plan()方法: tidb的慢SQL日志里会以hash值方法记载慢SQL的履行方案，然后运用tidb_decode_plan()函数即可解析。

(4) dashboard检查：tidb的PD组件包括dashboard功用，慢SQL、SQL核算页面能够检查每个SQL的履行方案

• OceanBase:

(1) explain SQL方法：包括BASIC、OUTLINE、EXTENDED、EXTENDED_NOADDR、PARTITIONS、FORMAT = {TRADITIONAL| JSON}多个展现选项，除了extended方法大部分状况展现的内容根本共同，extended方法时会添加hint、outline、plan type、optimizerinfo等信息。

(2) 运用体系视图方法：oceanbase在完成上一向尽力便利oracle dba运用，经过vplancacheplanexplain/vplan_cache_plan_explain/ vplanc​achep​lane​xplain/vplan_cache_plan_stat等视图能够检查履行方案及算子的执信息(如行数、时刻等)，相似oracle的v$sql、v$sql_plan等视图

(3) 因未布置ob 图形化办理渠道ocp，因而未看SQL履行方案的页面展现。

三、履行方案内容

• TiDB:

TiDB的履行方案展现与oracle相似，以缩进的方法展现算子间的层次关系，一起运用折线进行算子连接展现，当SQL杂乱履行进程较多时能够很明显看出处于同一缩进深度的算子，explian方法下履行方案包括算子信息(id列)、预估行数(estRows列)，拜访目标(access object列)、过滤条件和操作信息(operator info列)

运用explain analyze或检查慢SQL中记载的履行方案时还包括每个算子实践的回来行数(actRows列)、算子的履行时刻和散布核算(execution info列)、内存占用(memory)、磁盘读(dsik)

execution info列展现的内容如下：

tikv_task:{proc max:640ms, min:120ms, p80:260ms, p95:470ms, iters:4859, tasks:27}, scan_detail: {total_process_keys: 4861956, total_keys: 4861983, rocksdb: {delete_skipped_count: 420892, key_skipped_count: 4861956, block: {cache_hit_count: 202, read_count: 18548, read_byte: 493.0 MB}}}

execution info因为是和每个算子展现成一行，且信息较多输出时较多换行，对履行方案阅览有些影响，假如能放到下面进行额定展现的话，就能使履行方案进程展现看起来更便利些。

• OceanBase:

Oceanbase将履行方案区分为了本地履行方案、长途履行方案、散布式履行方案。履行方案展现十分接近oracle的展现方法，explain basic下展现履行方案和output&filter。 树形履行方案中包括算子展现id、算子内容(OPERATOR列)、拜访的目标信息(NAME列)、预估行数(EST. ROWS)、评价的本钱(COST)。output&filter展现的列过滤和投影后列信息，比较oracle展现的内容没有access信息，且列值可读性差。

在exteneded方法下还包括SQL运用HINT、SQL履行生产的outline(outline部分根本和oracle共同)、优化器的履行信息optimizer info。

Oceanbase中关于路径拜访的算子较少，现在只要TABLE GET(直接主键定位)、TABLE SCAN(全表或索引扫描回表)、LOOKUP TABLE(大局索引扫描回表)，针对履行方案中是否运用索引需要结合name列是否有索引以及filter中is_index_back=true判别，关于扫描方法不行直接和便利，比方索引全扫描、索引规模扫描、是否运用掩盖索引等。关于分区信息的显现ocenbase和oracle相同展现的分区partition id，tidb内展现的是分区名更直观一些。 ## 四、慢SQL记载

• TiDB:

超越slow_launch_time参数值的SQL会被记载到tidb_slow_query.log。可经过information_schema.CLUSTER_SLOW_QUERY或dashboard检查。

• Oceanbase:

履行时刻超越trace_log_slow_query_watermark参数值设置的会记载到observer.log。

运用视图vplancacheplanexplain/vplan_cache_plan_explain/ vplanc​achep​lane​xplain/vplan_cache_plan_stat也能够按条件过滤慢SQL，不过查询时假如没有指定ip\port\tenant\plan_id等条件是数据回来空行，即使count(*)整个基表表也是回来空。

此外还能够经过vsqlaudit视图查询会话和SQL履行信息，其相似于oracle的vsql_audit视图查询会话和SQL履行信息，其相似于oracle的vsqla​udit视图查询会话和SQL履行信息，其相似于oracle的vsession视图。

五、HINT

关于hint运用OceanBase和tidb的方法根本相同，oceanbase中除了常规的hint外，还能够像oracle相同运用 outline data作为hint内容。

六、履行方案绑定

• TiDB:

TiDB履行方案绑定功用叫SPM(sql plan managment)包括手动绑定履行方案、主动捕获履行方案和演进功用。履行SQL绑守时会将SQL进行标准化进行变量值的替换和空格转化等，在履行SQL时会将SQL进行标准化，与标准化后的SQL进行比对，假如一向则运用绑定的履行方案。TiDB中绑定SQL与原始SQL大小写不共同、空格换行不共同等不影响绑定运用。TiDB内不能运用SQL_digest/plan_digest等hash值方法进行SQL绑定，在创建和删去绑守时都必须运用原始SQL和HINT SQL，关于较长的杂乱SQL不是很便利。

履行方案绑定详细信息可参阅官方文档和专栏文章：tidb.io/blog/83b454…

• OceanBase:

Oceanbase的履行方案绑定可运用2种方法，2个从概念上都参阅了oracle，一个是运用outline方法进行履行方案绑定，一个是运用SPM方法进行绑定和履行方案捕获和演进(开源版不支撑SPM)。Outline运用方法和tidb创建SQL binding相似都是运用HINT SQL和原始SQL绑定，不过oceanbase的SQL绑定严格要求原始SQL和HINT SQL必须彻底共同（相似oracle的sql_id核算），大小写和空格对绑定有影响。Oceanbase支撑运用SQL_ID、PLAN_ID的值进行履行方案绑定，便利绑定操作。

无论TiDB还是OceanBase两个都不支撑HINT SQL运用force index类提示绑定履行方案。

Oceanbase的SPM履行方案办理和oracle十分相似，都是运用dbms_spm包进行办理，其语法根本共同，相同经过几个参数操控是否进行主动绑定和演进。

七、履行方案缓存

• TiDB:

运用Prepare/execute方法，Prepare时将参数化的 SQL 查询解析成 AST（抽象语法树），每次Execute时依据保存的 AST 和详细的参数值生成履行方案，关于Prepare的句子在榜首次execute时会检查该句子是否能够运用履行方案缓存(比方包括分区表、子查询的句子不能缓存)，假如能够则将句子履行方案放入到缓存中，后续的execute会首要检查缓存中是否有履行方案可用，有的话则进行合法性检查，经过后运用缓存的履行方案，不然从头生成履行方案放入到缓存中。

缓存是session级的，以LRU链表方法办理，链表元素为kv对，key由库名、prepare句子标识、schema版本、SQL_Mode、timezone组成，value是履行方案。经过prepared-plan-cache下的相关选项能够操控是否启用缓存、缓存条目数和占内存大小。

• OceanBase:

Oceanbase内除了能够运用prepare方法外，oceanbase对履行方案缓存参照oracle做了大量作业。和Oracle rac相似每个observer只办理自己节点上的缓存，不同节点相同SQL缓存的履行方案或许不同。

Oceanbase将SQL文本进行参数化处理后作为履行方案缓存的键值key，value是履行方案。Oceanbase的SQL匹配也参阅了oracle，引进了cursor_sharing参数和HINT，参数值为excat要求SQL匹配必须彻底相同，包括空格、大小写、字段值等。参数值为force时则以参数化后的SQL进行匹配。

除此之外ocenabase也引进了自适应游标同享ACS功用，针对一个SQL在运用不同字段值时运用不同的履行方案，经过参数可操控是否开启该功用。

缓存的履行方案可经过经过vplancacheplanexplain/vplan_cache_plan_explain/ vplanc​achep​lane​xplain/vplan_cache_plan_stat检查。

开源版不支撑cursor_sharing和ACS功用。

八、核算信息

• TiDB:

tidb核算信息搜集包括主动核算信息搜集和手动核算信息搜集。主动核算信息搜集依据表的状况和参数tidb_auto_analyze_start_time/tidb_evolve_plan_task_end_time/ tidb_auto_analyze_ratio决定何时进行核算信息搜集。手动核算信息搜集依据需要随时履行analyze SQL。

TiDB支撑feedback特性，即在SQL履行时依据实践的履行信息去更新核算信息，以使核算信息依据准确和及时更新，不过因为feedback特性会导致一些问题，改特性默认为封闭。Oracle数据库在11g引进该特性时也引起一些问题，大部分状况DBA会将该功用封闭。

Tidb内的核算信息能够运用show stats_meta/stats_buckets/stats_histograms等检查。

关于核算信息搜集的更详细搜集可参阅：tidb.io/blog/92447a…

• OceanBase:

Oceanbase社区版不支撑analyze句子搜集核算信息(商业版3.2才引进)，存储层进行兼并时更新核算信息，能够手艺触发兼并操作进行更新。SQL履行时从memtable进行动态采样，采样比例固定，无法更改。

相关核算信息可从_all_table_stat，__all_column_stat, __all_histogram_stat等体系视图检查。

九、SQL trace

• TiDB:

tidb 直接运用trace SQL履行即可展现trace成果。Operation列展现函数调用层次和拜访的region信息，startTS了展现该步的开始时刻，duartion展现该步的耗费时刻。

• OceanBase:

OceanBase的trace运用相似和成果相似于mysql的Profiling。履行进程如下：

(1) 开启trace: SET ob_enable_trace_log = 1;

(2) 履行SQL

(3) Show trace检查，然后SET ob_enable_trace_log =0 封闭

从展现成果上看其信息的直观性和可用性上不如tidb。

十、遇到的问题

• TiDB:

(1) 履行方案中不显现不显现子查询的表信息，无法判别运用的扫描方法

该问题现在暂未完成修正: github.com/pingcap/tid…

oceanbase履行方案如下：

• OceanBase:

(1) 关于子查询中不存在的列不会报错依然继续履行

Tidb履行如下：

(2) Oceanbase无法运用索引

按id列进行小规模查询时无法运用id列索引，履行手艺兼并后依然是全表扫描履行方案。

tidb履行方案：

(3) 不同的index hint方法导致履行方案不同

TIDB履行方案：

(4) explian展现的履行方案不能运用绑定后的Outline ，数据字典内记载的履行方案运用了索引

Tidb履行方案：

(5) 履行Prepare后会导致会话断开，再次履行后成功，关于交互式客户端oceanbase不支撑显现查询成果。

TiDB履行方案：

(6) Obproxy或许会和多个后端observer树立连接，导致相同会话履行的慢SQL会被记载到多个observer的observer.log内(ob内运用数据字典查询慢SQL信息会更好些)。

十一、总结

个人认为从功用上看oceanbase的履行方案办理要TiDB更丰厚些，如SPM、ACS等，但从实践运用看无论是操作的杂乱性、履行方案的可读性、优化器的可靠性都要因为oceanbase。Oceanbase在各方面在尽力的向oracle兼容，比方体系视图、SPM办理、自适应游标同享、等候事件等，因架构不同、经历积累等和oracle比还是有着不小的距离。

针对TiDB建议如下:

(1) 履行方案绑定办理能够运用sql_digest、plan_digest等，可防止运用SQL句子

(2) 履行方案缓存做成大局办理方法，防止多个会话对相同SQL进行缓存，浪费内存空间

(3) Explain analyze的execution info 在履行方案下面独立展现，不然履行方案太长不便利阅览。

作者：@h5n1 发布时刻：2022/4/12 原文链接：tidb.net/blog/f1fd17…