遇到慢SQL、SQL报错，应如何快速定位问题 | OceanBase优化实践

在数据库的使用中，大家时常会遇到慢SQL，或执行出错的SQL。对于某些SQL问题，其错误原因显而易见，但也有不少情况难以直观判断。面对这类问题，我们应当如何应对？如何准确识别SQL错误的根源？是否需要优化SQL本身？还是数据库的配置存在不足？接下来，将简要介绍如何迅速定位SQL问题的策略。

但在深入探讨之前，让我们先一同了解，当一条SQL语句进入OceanBase数据库系统执行时，它究竟会经过哪些模块和路径。

访问路径

首先我们从SQL的访问路径开始介绍，一条SQL从应用发出之后，一般会经过负载均衡（根据情况选择是否需要），然后到OBProxy，然后再到OBServer。大概流程如下图所示：

OBProxy主要起到一个路由转发的作用，以及快速解析，根据OceanBase数据库中数据副本分布情况，直接将请求快速发送到对应的OBServer上。

SQL在进入OBServer之后，还会经历数据库内部很多模块，具体如下：

SQL的在数据库内部的执行过程，这些模块具体的含义，可以参考官网文档：SQL 请求执行流程，在整个SQL执行过程中，会首先根据SQL的ip、port、自增序列号等信息生成一个全局唯一的trace_id，后续的sql跟踪，我们都使用这个trace_id来对sql进行定位追踪。

SQL错误

这种问题一般都比较好处理，大多都是sql写的格式不对，或者库、表、列名等不存在，或者OceanBase语法不支持等，一般情况，根据返回的错误信息，就大致可以判断出错误原因。

但也有一些很隐蔽的错误，一时很难判断出具体是哪里错了，这个时候就要借助错误日志来帮助我们进行判断了，这里就举一个例子，这是在一个用户那里实实在在遇到的问题，用户的场景比较复杂，拿OceanBase用来做数据的清洗，将多张表进行关联计算，然后将数据写入到结果表中，而在执行其中一条SQL过程中，收到了这样一个报错：

ERROR 1292 (22007): Incorrect value 

当时用户收到这个报错后很茫然，因为用户的SQL长达200多行，并且有多层嵌套子查询和多张表关联查询，所以一时间很难判断出来是哪里出现了错误，SQL大致如下（脱敏后）：

REPLACE INTO abc.table1(
  m_id,
  st_id,
  con_id,
  `date`,
  t_ord,
  t_role,
  tag,
  con_pri,
  con_qu,
  con_in,
  update_time
)
SELECT 
	tmp5.m_id,
	tmp5.st_id,
	tmp5.con_id,
	tmp5.`date`,
	tmp5.t_ord_96,
	tmp5.t_role,
	tmp5.tag,
	cast(sum(tmp5.con_pri) as decimal(20,6)) as con_pri,
	cast(sum(tmp5.con_qu) as decimal(20,6)) as con_qu,
	cast(sum(tmp5.con_in) as decimal(20,6)) as con_in,
	current_timestamp
FROM 
	(
    SELECT 
    tmp4.m_id,
    tmp4.st_id,
    tmp4.con_id,
    tmp4.`date`,
    tmp4.t_ord,
    dstl2.t_ord_96,
    tmp4.t_role,
    tmp4.tag,
    case
    when tmp4.t_ord = dstl2.t_ord_96 then con_pri
    else 0
    end as con_pri,
    case
    when tmp4.t_ord = dstl2.t_ord_96 then con_qu
    else 0
    end as con_qu,
    case
    when tmp4.t_ord = dstl2.t_ord_96 then con_in
    else 0
    end as con_in
    FROM 
    (
      SELECT
      tmp3.m_id,
      tmp3.st_id,
      tmp3.con_id,
      tmp3.`date`,
      tmp3.t_ord_96 as t_ord,
      tmp3.t_role,
      tmp3.tag,
      tmp3.con_pri,
      cast(tmp3.con_qu as decimal(20,6)) as con_qu,
      cast(tmp3.con_qu * tmp3.con_pri as decimal(20,6)) as con_in
      FROM
      (
        SELECT 
        tmp2.m_id,
        tmp2.st_id,
        tmp2.con_id,
        tmp2.`date`,
        tmp2.t_ord_96,
        case
        when tmp2.con_name like '%xxx%' then 1
        when tmp2.con_name like '%x%' then 2
        when tmp2.con_name like '%xx%' then 3
        else
        case
        when tmp2.contract_type_name like '%xx%' then 4
        else 5
        end
        end as tag,
        case 
        when tmp2.con_name like '%xxxxx%' then tmp2.vendee_price
        else tmp2.sale_price
        end as con_pri,
        case 
        when tmp2.con_name like '%xxxxx%' then tmp2.vendee_energy
        else tmp2.sale_energy
        end as con_qu,
        tmp2.t_role
        FROM
        (
          select 
          tmp.m_id,
          tmp.st_id,
          tmp.st_name,
          tmp.member_id,
          tmp.con_id,
          tmp.con_name,
          dd.`date`,
          tmp.t_ord_96,
          tmp.sale_energy / (datediff(tmp.timepart_endtime, tmp.timepart_starttime) + 1) / tmp.re as sale_energy,
          tmp.sale_price,
          tmp.vendee_energy / (datediff(tmp.timepart_endtime, tmp.timepart_starttime) + 1) / tmp.re as vendee_energy,
          tmp.vendee_price,
          tmp.timepart_starttime,
          tmp.timepart_endtime,
          tmp.seller_member_name,
          tmp.contract_type_name,
          tmp.t_role
          from
          (
            select 
            tmp1.*,
            dstl.t_ord_96,
            count(1) over(PARTITION by member_id, con_id, time_division_range, timepart_endtime, timepart_starttime) as re
            from 
            (
              select 
              distinct 
              spcdp.m_id,
              ds.st_id,
              ds.st_name,
              spcdp.member_id, 
              spcdp.con_id,
              dc.con_name,
              spcdp.sale_energy, 
              spcdp.sale_price, 
              spcdp.vendee_energy, 
              spcdp.vendee_price, 
              spcdp.time_division_code,
              spcdp.time_division_name,
              case
              when dc.con_name like '%xx%' then 
              case 
              when substr(date_add(cast(concat('2022-10-01 ', right(spcdp.time_division_range, 5), ':00') as datetime), interval 1 hour), 12, 5) = '00:00' then concat(left(spcdp.time_division_range, 6), '24:00')
              else concat(left(spcdp.time_division_range, 6), substr(date_add(cast(concat('2022-10-01 ', right(spcdp.time_division_range, 5), ':00') as datetime), interval 1 hour), 12, 5))
              end
              else spcdp.time_division_range
              end as time_division_range, 
              spcdp.timepart_endtime,
              spcdp.timepart_starttime,
              dc.seller_member_name,
              dc.contract_type_name,
              case 
              when locate('x',dc.con_name) > 0 then 1
              when locate('x',dc.con_name) > 0 then 2
              else if(dc.con_qu>0,2,1)
              end as t_role
              from 
              (select distinct m_id, member_id, con_id, sale_energy, sale_price, vendee_energy, vendee_price, time_division_code, time_division_name, time_division_range, timepart_endtime, timepart_starttime from 
               select 
               DISTINCT
               if(spcdp.m_id is null,spcdpa.m_id,spcdp.m_id) as m_id,
               if(spcdp.member_id is null,spcdpa.member_id,spcdp.member_id) as member_id,
               if(spcdp.con_id is null,spcdpa.con_id,spcdp.con_id) as con_id,
               if(spcdp.sale_energy is null,spcdpa.sale_energy,spcdp.sale_energy) as sale_energy,
               if(spcdp.sale_price is null,spcdpa.sale_price,spcdp.sale_price) as sale_price,
               if(spcdp.vendee_energy is null,spcdpa.vendee_energy,spcdp.vendee_energy) as vendee_energy,	
               if(spcdp.vendee_price is null,spcdpa.vendee_price,spcdp.vendee_price) as vendee_price,
               if(spcdp.time_division_code is null,spcdpa.time_division_code,spcdp.time_division_code) as time_division_code,
               if(spcdp.time_division_name is null,spcdpa.time_division_name,spcdp.time_division_name) as time_division_name,
               if(spcdp.time_division_range is null,spcdpa.time_division_range,spcdp.time_division_range) as time_division_range,
               if(spcdp.timepart_endtime is null,spcdpa.timepart_endtime,spcdp.timepart_endtime) as timepart_endtime,
               if(spcdp.timepart_starttime is null,spcdpa.timepart_starttime,spcdp.timepart_starttime) as timepart_starttime,
               if(spcdp.creator is null,spcdpa.creator,spcdp.creator) as creator,
               if(spcdp.creation_time is null,spcdpa.creation_time,spcdp.creation_time) as creation_time,
               if(spcdp.modifier is null,spcdpa.modifier,spcdp.modifier) as modifier,
               if(spcdp.modification_time is null,spcdpa.modification_time,spcdp.modification_time) as modification_time
               from
               (
                 select * from ods.table2 where modification_time >= date_format(date_sub(current_date, interval 1 day), '%Y-%m-%d %T')
               ) spcdp  
               full join 
               (
                 select * from ods.table2_xxx where modification_time >= date_format(date_sub(current_date, interval 1 day), '%Y-%m-%d %T')
               ) spcdpa  
               on spcdp.m_id = spcdpa.m_id and spcdp.member_id = spcdpa.member_id and spcdp.con_id = spcdpa.con_id
               and spcdp.time_division_code = spcdpa.time_division_code and spcdp.timepart_starttime = spcdpa.timepart_starttime
               and spcdp.timepart_endtime = spcdpa.timepart_endtime
              )
              where m_id = 'PXBGS' and time_division_range <> '') spcdp
            inner join (select * from abc.table3 where service_provider_id = 1) ds on spcdp.member_id = ds.counterparty_code
            inner join (select * from abc.table4 where is_deleted <> 1) dc on spcdp.con_id = dc.con_id and ds.st_id = dc.st_id 
            and date(spcdp.timepart_starttime) between dc.contract_start_date and dc.contract_end_date
          ) tmp1
          left join 
          (
            select
            t_ord_96,
            CASE 
            when end_time_96 = '00:00:00' then '24:00'
            else left(end_time_96, 5)
            END as end_time_96
            from 
            abc.dim_spot_time_list
          ) dstl on dstl.end_time_96 > left(tmp1.time_division_range, 5) and dstl.end_time_96 <= right(tmp1.time_division_range, 5)
        ) as tmp
        left join abc.dim_date dd on dd.`date` BETWEEN date(tmp.timepart_starttime) and date(timepart_endtime)
      ) as tmp2
    ) as tmp3
    where tmp3.t_ord_96 is not null and tmp3.con_id <> 'xxxxxxxxxxxx' 
  ) as tmp4
		left join abc.dim_spot_time_list dstl2 on 1 = 1
	) as tmp5
	group by tmp5.m_id, tmp5.st_id, tmp5.con_id, tmp5.`date`, tmp5.t_ord_96, tmp5.t_role, tmp5.tag;

从这个SQL文本来看，整体还是比较复杂，想快速找到问题根因还是比较困难，这个时候就需要我们根据SQL执行过程中的trace_id，来一步步追踪问题的根因。

这里先说结论，通过对日志过滤排查，我们发现是字段类型强转，导致转出来的日期字段是无效的，所以报除了这个错误，当时获取到的日志如下（部分截取）：

从日志的第一行，我们就可以看到datetime is invalid or out of range的报错，在这里就基本可以判断是datetime类型有问题，第二行的提示则更明显：failed to convert string to datetime，所以我们很快就可以定位到是在做string转datetime类型的时候，出现了错误，通过回看SQL可以找到，有两处使用cast函数来做字符串类型转时间类型的转换，然后根据用户提供的表数据，我们对问题进行复现，确信就是这里的错误。SQL中类型转换如下：

cast(concat('2022-10-01 ', right(spcdp.time_division_range, 5), ':00') as datetime)

那我们是怎么快速找到这条日志的呢，下面我把问题简化，重新复现报错现场，看下是怎么一步步找到关键日志，发现问题的。具体如下，简单创建两张表:

t1表：

CREATE TABLE `t1` (
  `a_id` int(11) DEFAULT NULL,
  `a_name` varchar(10) DEFAULT NULL,
  `a_time` varchar(10) DEFAULT NULL
)

t2表：

CREATE TABLE `t2` (
  `t_id` int(11) DEFAULT NULL,
  `t_name` varchar(10) DEFAULT NULL,
  `t_time` datetime DEFAULT NULL
)

其中t2表，是目标写入表，t1表是源数据表，t1表和t2表区别主要是第三个字段的类型不一样，一个是varchar，一个是datetime类型，源数据表t1中数据如下：

obclient [test]> select * from t1;
+------+--------+--------+
| a_id | a_name | a_time |
+------+--------+--------+
|    1 | test   | 24:00  |
+------+--------+--------+
1 row in set (0.011 sec)

模拟数据清洗并写入

obclient [test]> insert into t2 select a_id, a_name,cast(concat('2022-10-10 ', right(tb.a_time,5), ':00') as datetime) from t1 tb;
ERROR 1292 (22007): Incorrect value

可以看到出现了类似的报错，接下来我们就需要去日志里定位到这个报错，因为OceanBase的日志打印比较多，如果直接去找是很难快速定位到跟这条SQL相关的日志，这里就需要用到trace_id。前面我们说到每条SQL进入到数据库，都会产生一个唯一的trace_id，那这个trace_id是怎么获取呢，这里有几种方式：

方式一：

在SQL执行完成之后，通过select last_trace_id();获取

obclient [test]> select last_trace_id();
+-----------------------------------+
| last_trace_id()                   |
+-----------------------------------+
| YB42AC18FF11-0005FE3D398CC982-0-0 |
+-----------------------------------+
1 row in set (0.001 sec)

方式二：

通过查询 GV$OB_SQL_AUDIT 审计视图查询获取，根据query_sql字段过滤查询的关键字，获取对应的trace_id，关于审计视图的各字段含义，可参考官方文档：GV$OB_SQL_AUDIT

obclient [test]> select SVR_IP,SVR_PORT,TRACE_ID,,TENANT_NAME,SQL_ID,QUERY_SQL 
    ->     from oceanbase.gv$ob_sql_audit
    ->     where query_sql like "%right(tb.a_time,5)%"\G;
*************************** 1. row ***************************
                         SVR_IP: 172.24.255.17
                       SVR_PORT: 2882
                       TRACE_ID: YB42AC18FF11-0005FE3D398CC982-0-0
                    TENANT_NAME: obtest
                         SQL_ID: D8F4A48653895C3AAACE903CA04EDD21
                      QUERY_SQL: insert into t2 select a_id, a_name,cast(concat('2022-10-10 ', right(tb.a_time,5), ':00') as datetime) from t1 tb
1 rows in set (0.224 sec)

方式三：

开启enable_rich_error_msg参数，不过这个是集群级别的，需要在sys租户下开启

开启方式：

alter system set enable_rich_error_msg=true;

在开启之后，如果SQL执行报错，会自动返回trace_id和ip信息

obclient [test]> insert into t2 select a_id, a_name,cast(concat('2022-10-10 ', right(tb.a_time,5), ':00') as datetime) from t1 tb;
ERROR 1292 (22007): Incorrect value
[172.24.255.17:2882] [2023-08-03 20:42:36.361996] [YB42AC18FF11-0005FE3D398CC986-0-0]

以上三种方式，我们一般会采用第二种方式，方式一只能获取到trace_id，但是获取不到OBServer的IP信息，因为OceanBase为分布式数据库，一套集群一般会有多个OBServer节点，如果没有IP信息，我们很难得知这条SQL是在哪个OBServer节点上执行的。所以是需要这个IP信息方便我们拿着trace_id直接去机器上过滤日志。方式三需要开启集群级别的参数，有的租户并不一定需要这个，并且展示信息相对较少。

通过获取到的trace_id，以及SVR_IP信息，我们直接到172.24.255.17这台机器的/home/admin/oceanbase/log目录下，过滤observer.log，得到如下日志：

从日志的前两行中，可以看到这次的报错，和用户日志中过滤出来的报错是一样的，因此我们就可以判断是这里的cast转换出现了错误。

这里为什么这样转换是不行的呢，我们可以看到在t1表中，a_time字段是varchar类型，具体数值是 24:00 ，通过concat('2022-10-10 ', right(tb.a_time,5), ':00') 拼接之后，组成的字符串是 "2022-10-10 24:00:00" ，乍一看貌似没有什么问题，但为什么会转换失败？实际我们细心观察就会发现，2022-10-10 24:00:00 在计算机中是一个非法时间，2022-10-10 24:00:00 其实已经到 2022-10-11 00:00:00，所以这块我们建议用户对这个字符串做下修改，不要使用24:00:00。

修改之后我们再来看一下执行情况。

首先t1表内容

obclient [test]> select * from t1;
+------+--------+--------+
| a_id | a_name | a_time |
+------+--------+--------+
|    1 | test   | 00:00  |
+------+--------+--------+
1 row in set (0.001 sec)

再次执行写入

obclient [test]> insert into t2 select a_id, a_name,cast(concat('2022-10-11 ', right(tb.a_time,5), ':00') as datetime) from t1 tb;
Query OK, 1 row affected (0.003 sec)

obclient [test]> select * from t2;
+------+--------+---------------------+
| t_id | t_name | t_time              |
+------+--------+---------------------+
|    1 | test   | 2022-10-11 00:00:00 |
+------+--------+---------------------+
1 row in set (0.001 sec)

可以看到执行写入成功，问题得以解决。

在实际生产过程中，我们还会遇到其他很多类型的错误，大多都是可以通过这种方式快速定位和解决问题。另外还有一种情况，就是我们遇到了慢SQL，导致整个数据库系统变卡，也影响到其他SQL的执行。下面就来看下如何快速定位慢SQL。

慢SQL

慢SQL对于DBA来说，一直是一个比较头疼的地方，当遇到慢SQL的时候，总是需要想各种办法去优化慢SQL，如果不快速优化，就会引发一系列问题，那么在OceanBase中我们如何判断是慢SQL，以及如何发现慢SQL呢。

OceanBase中有一个参数 trace_log_slow_query_watermark 用来设置慢SQL的阈值，当SQL的执行超过这个阈值，那么OceanBase就会认为这是一条慢SQL，然后被记录，这个值默认是 1 秒。

那么，这些慢SQL信息具体记录在哪些地方呢，我们如何快速找到它呢？

方式一：

首先，我们前面提到所有的SQL的执行都会记录在observer.log的日志里，慢SQL也不例外，在observer.log日志里，我们可以过滤 slow query 关键字，就能获取到执行超过 1 秒的慢SQL，例如下面这条日志

这条日志其实记录了很多信息，包括SQL的trace_id，以及执行总时间total_time和各个模块的执行时间。

方式二：

在OBProxy的日志目录里，专门有一个 obproxy_slow.log 的日志，这个日志也会记录所有的慢SQL信息，我们可以直接查看这个日志，发现执行慢的SQL

obproxy的慢SQL日志中总共有24个字段，根据这些字段，我们也可以获取到一些信息，有些字段为暂时留空，这些字段依次是

方式三：

如果系统当前时段就很慢，可以查询正在执行的比较慢的SQL，通过视图 __all_virtual_processlist 根据 time 字段排序，获取当前系统中，正在执行的慢SQL。

查询SQL如下

SELECT USER,
   tenant,
   sql_id,
   concat(time, 's') as time,
   info,
   svr_ip,
   svr_port,
   trace_id
FROM __all_virtual_processlist
WHERE STATE = 'ACTIVE'
ORDER BY time DESC LIMIT 1

现在模拟一个慢SQL， select /*+ query_timeout(100000000) */ sleep(100); 查询结果如下

+------+--------+----------------------------------+------+---------------------------------------------------+---------------+----------+-----------------------------------+
| USER | tenant | sql_id                           | time | info                                              | svr_ip        | svr_port | trace_id                          |
+------+--------+----------------------------------+------+---------------------------------------------------+---------------+----------+-----------------------------------+
| root | obtest | DE47F6BC20D6E36C14AA4D90BDE3B083 | 2s   | select /*+ query_timeout(100000000) */ sleep(100) | 172.24.255.19 |     2882 | YB42AC18FF13-0005FE3D2CBF2D57-0-0 |
+------+--------+----------------------------------+------+---------------------------------------------------+---------------+----------+-----------------------------------+
1 row in set (0.003 sec)

方式四：

如果有OCP的话，也是可以在OCP上直接查看慢SQL，进到具体的租户下面，然后进到SQL诊断中，有慢SQL页面，这里的SQL文本，都是有相同SQL_ID的SQL

这里再解释下SQL_ID，SQL_ID是每条SQL进入数据库之后，会根据SQL字符串生成一个md5值，所以执行相同的SQL 会有相同的SQL_ID，但是trace_id是不一样的。

想要查看某条SQL具体是哪次执行慢了，可以点击SQL文本进到下一个页面，拿到执行慢的那一次的 SQL 的trace_id。

通过这几种方式，我们就可以很快获取到系统中执行的慢SQL，不过前两种方式和第四种方式只能获取到trace_id，而第三种方式可以直接获取到执行的SQL，以及SQL_ID。对于前两种方式，想要看具体的内容，还需要再进一步查询。这里又用到我们的 GV$OB_SQL_AUDIT 视图，可以根据视图中的trace_id直接定位到对应的SQL内容：

obclient [oceanbase]> select SVR_IP,SVR_PORT,TRACE_ID,TENANT_NAME,SQL_ID,QUERY_SQL,PLAN_ID
    ->     from gv$ob_sql_audit 
    ->     where trace_id = "YB42AC18FF13-0005FE3D2CBF2D57-0-0"\G;
*************************** 1. row ***************************
                         SVR_IP: 172.24.255.19
                       SVR_PORT: 2882
                       TRACE_ID: YB42AC18FF13-0005FE3D2CBF2D57-0-0
                    TENANT_NAME: obtest
                         SQL_ID: DE47F6BC20D6E36C14AA4D90BDE3B083
                      QUERY_SQL: select /*+ query_timeout(100000000) */ sleep(100)
                        PLAN_ID: 2518
1 row in set (0.146 sec)

通过这个查询，我们就知道了具体是哪条SQL执行慢了，并且获取到了SQL执行计划的PLAN_ID，接着就可以根据PLAN_ID去查找这条SQL的执行计划，根据执行计划再进一步排查

获取执行计划相关信息

obclient [oceanbase]> SELECT tenant_id,
    ->    svr_ip,
    ->    svr_port,
    ->    sql_id,
    ->    plan_id,
    ->    last_active_time,
    ->    first_load_time,
    ->    outline_data
    -> FROM GV$OB_PLAN_CACHE_PLAN_STAT
    -> WHERE TENANT_ID = 1012
    -> AND SQL_ID = 'DE47F6BC20D6E36C14AA4D90BDE3B083'
    -> AND SVR_IP = '172.24.255.19'
    -> AND SVR_PORT = 2882;
*************************** 1. row ***************************
       tenant_id: 1012
          svr_ip: 172.24.255.19
        svr_port: 2882
          sql_id: DE47F6BC20D6E36C14AA4D90BDE3B083
         plan_id: 2518
last_active_time: 2023-08-04 11:42:47.834366
 first_load_time: 2023-08-04 11:42:47.834366
    outline_data: /*+BEGIN_OUTLINE_DATA QUERY_TIMEOUT(100000000) OPTIMIZER_FEATURES_ENABLE('4.0.0.0') END_OUTLINE_DATA*/
1 row in set (0.019 sec)

得到这个查询的执行计划的编号（plan_id），这个执行计划第一次生成的时间（first_load_time）以及最后一次被使用的时间（last_active_time）

接着，就可以根据plan_id来获取这条SQL的物理执行计划

obclient [oceanbase]> SELECT OPERATOR, NAME, ROWS, COST FROM GV$OB_PLAN_CACHE_PLAN_EXPLAIN
    ->     WHERE TENANT_ID = 1012 AND
    ->     SVR_IP = '172.24.255.19' AND
    ->     SVR_PORT = 2882 AND
    ->     PLAN_ID = 2518;
+-----------------+------+------+------+
| OPERATOR        | NAME | ROWS | COST |
+-----------------+------+------+------+
| PHY_EXPR_VALUES | NULL |    1 |    0 |
+-----------------+------+------+------+
1 row in set (0.001 sec)

如果想要获取SQL的逻辑执行计划，可以直接使用 explain SQL 获取

obclient [test]> explain select /*+ query_timeout(100000000) */ sleep(100);
+--------------------------------------------------------------+
| Query Plan                                                   |
+--------------------------------------------------------------+
| ==========================================                   |
| |ID|OPERATOR  |NAME|EST.ROWS|EST.TIME(us)|                   |
| ------------------------------------------                   |
| |0 |EXPRESSION|    |1       |1           |                   |
| ==========================================                   |
| Outputs & filters:                                           |
| -------------------------------------                        |
|   0 - output([sleep(cast(100, DECIMAL(3, 0)))]), filter(nil) |
|       values({sleep(cast(100, DECIMAL(3, 0)))})              |
+--------------------------------------------------------------+
9 rows in set (0.007 sec)

接着就可以根据执行计划，来判断问题的原因。执行计划解读，可参考官网文档：执行计划，定位到问题之后，我们也有很多优化的方式，这些后续我们再展开来将，其中包括 hint， outline绑定等。

另外，在OceanBase 4.0版本之后，我们也推出了全链路追踪的功能，依靠全链路追踪，可以更快速的定位到一条SQL具体是哪里执行慢。相关全链路追踪文档，可以参考这里：OceanBase 4.0 解读：全链路追踪要解决什么问题？从一条慢SQL说起