一、前言

         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应用，通过v$plan\_cache\_plan\_explain/ v$plan\_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。

         应用视图v$plan\_cache\_plan\_explain/ v$plan\_cache\_plan\_stat也能够按条件过滤慢SQL，不过查问时如果没有指定ip\port\tenant\plan\_id等条件是数据返回空行，即便count(*)整个基表表也是返回空。

         此外还能够通过v$sql\_audit视图查问会话和SQL执行信息，其相似于oracle的v$session视图。

五、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不是很不便。

         执行打算绑定详细信息可参考官网文档和专栏文章：https://tidb.io/blog/83b454f1

  • 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在应用不同字段值时应用不同的执行打算，通过参数可管制是否开启该性能。

         缓存的执行打算可通过通过v$plan\_cache\_plan\_explain/ v$plan\_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等查看。

         对于统计信息收集的更具体收集可参考：https\://tidb.io/blog/92447a59

  • 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)    执行打算中不显示不显示子查问的表信息，无奈判断应用的扫描形式

该问题目前暂未实现修复: https://github.com/pingcap/ti...

         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
原文链接：https://tidb.net/blog/f1fd1733