[OceanBase] 慢SQL案例一

一、现象

目前在OB 2230环境发现一个问题如下：
同一个MySQL租户下面的两个库：elcs和core_elcs_0430，执行同一条SQL。SQL中涉及的表的数据量以及包含的索引都相同，但执行效率相差很大，前者耗时1s，后者耗时51s。

二、排查过程

两张表的数据量差不多，索引相同

检查生成的执行计划有差异

elcs库，1s：
--------------------------------------------------------------------------
|0 |LIMIT                 |                             |17       |250305|
|1 | TOP-N SORT           |                             |17       |250303|
|2 |  SUBPLAN FILTER      |                             |17       |249857|
|3 |   HASH JOIN          |                             |32       |28080 |
|4 |    TABLE SCAN        |secuserrol4_                 |40       |321   |
|5 |    HASH JOIN         |                             |32       |27563 |
|6 |     NESTED-LOOP JOIN |                             |129      |9059  |
|7 |      NESTED-LOOP JOIN|                             |80       |5976  |
|8 |       HASH JOIN      |                             |64       |699   |
|9 |        TABLE SCAN    |transactio0_                 |23       |71    |
|10|        TABLE SCAN    |groupentit1_                 |116      |321   |
|11|       TABLE SCAN     |parametere2_(idx_pt_param_02)|1        |84    |
|12|      TABLE SCAN      |taskaction3_(idx_pt_param_01)|2        |38    |
|13|     TABLE SCAN       |secroletas5_                 |4298     |10591 |
|14|   TABLE SCAN         |secuserage6_                 |1        |221772|
==========================================================================

core_elcs_0430库，51s：
| ==========================================================================
|ID|OPERATOR              |NAME                         |EST. ROWS|COST  |
--------------------------------------------------------------------------
|0 |LIMIT                 |                             |1        |233172|
|1 | TOP-N SORT           |                             |1        |233172|
|2 |  SUBPLAN FILTER      |                             |1        |233172|
|3 |   NESTED-LOOP JOIN   |                             |1        |11401 |
|4 |    HASH JOIN         |                             |1        |11400 |
|5 |     TABLE SCAN       |secuserrol4_                 |1        |321   |
|6 |     HASH JOIN        |                             |1        |11080 |
|7 |      TABLE SCAN      |secroletas5_                 |1        |10591 |
|8 |      NESTED-LOOP JOIN|                             |1        |484   |
|9 |       HASH JOIN      |                             |2        |400   |
|10|        TABLE SCAN    |transactio0_                 |1        |70    |
|11|        TABLE SCAN    |groupentit1_                 |4        |319   |
|12|       TABLE SCAN     |parametere2_(idx_pt_param_02)|1        |84    |
|13|    TABLE SCAN        |taskaction3_                 |1        |74    |
|14|   TABLE SCAN         |secuserage6_                 |1        |221772|
==========================================================================

检查内部统计信息有差异，同一张表taskaction3_，elcs库能查到统计信息，core_elcs_0430库查不到

统计信息对比如截图：

OceanBase会在合并的时候收集表的统计信息，尝试做一次集群大合并之后再测试，并未解决问题。

三、解决

问题关键点在于 core_elcs_0430库的统计信息为什么为空，而如果统计信息未收集，为什么elcs库却是有统计信息的。这里忽略了一个关键点，其实可以去确认下elcs库的统计信息的更新时间点是否是最近一次合并完成时间。

查阅官网合并相关参数，发现了一个关键参数：merge_stat_sampling_ratio，解释如下：

顾名思义，控制合并时是否采集统计信息以及采样率。

查看这个集群的这个参数时，发现值竟然为0（原因无从查起）。

通过某监控平台检查该集群参数变化历史，这个参数在很早前就为0，elcs库为初始库一直存在，core_elcs_0430库是6月份才创建的，那么就可以确定

• elcs库用的还是旧的统计信息，但数据没怎么变化的话也可以按照代价生成较为准确的执行计划；
• core_elcs_0430库在每日合并时并不会收集最新统计信息，所以统计信息为空

最后修改参数: alter system set merge_stat_sampling_ratio=100

再合并之后，查询以及执行计划都正常了。