---
title: 存在隐式类型转换的大 IN 请求硬解析耗时高-OceanBase数据库使用指南
description: 了解OceanBase数据库在实际应用中关于 存在隐式类型转换的大 IN 请求硬解析耗时高相关的常见问题和使用技巧，帮助您快速解决 存在隐式类型转换的大 IN 请求硬解析耗时高的难题。
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

# 存在隐式类型转换的大 IN 请求硬解析耗时高

更新时间：2026-05-15 09:06

适用版本： V3.1.x、V3.2.x、V4.1.x、V4.2.x 内容类型：Troubleshoot  

## 问题现象

OceanBase 数据库 V3.x 版本引入静态执行引擎后，涉及类型转换时需要显式的在解析阶段添加 cast 表达式。对一个超长的 inlist 而言，当类型转换的 cast 需要增加在 inlist 上时，需要对 inlist 中的每个元素都添加 cast。添加的数量正比于 inlist 中元素的个数。之后在解析和优化阶段，需要对 inlist 中的 cast 进行类型推导，常量折叠等操作，这会消耗大量的时间。通常长度达到 2-3K、且存在隐式转换的的 SQL 硬解析耗时就会达到秒级。

## 关键诊断信息

### 触发条件

存在一个大 inlist，并且 inlist 中的元素和 in 的左值类型不同，需要对 inlist 的元素添加 cast。典型的场景如，其中 c1 的类型为数值型。此外，in 左右两侧字符集不同时也可能出现。

```shell
c1 in ('1','2','3' ...,'1000"); // c1 为数值型，数值型和字符串比较时，需要将字符串转换为数值型

```

### 事前巡检

巡检带超大 inlist 的 SQL，参考如下语句。

```shell
-- OceanBase 数据库 V3.x 版本
SELECT tenant_id,
       param_count,
       query_sql
FROM
  (SELECT tenant_id,
          query_sql,
          LENGTH(param_infos) - LENGTH(REPLACE(param_infos, '{', '')) AS param_count
   FROM oceanbase.gv$plan_cache_plan_stat)
WHERE query_sql LIKE '%in %(%'
  AND param_count > 200
ORDER BY param_count DESC LIMIT 5;

-- OceanBase 数据库 V4.x 版本
SELECT tenant_id,
       param_count,
       query_sql
FROM
  (SELECT tenant_id,
          query_sql,
          LENGTH(param_infos) - LENGTH(REPLACE(param_infos, '{', '')) AS param_count
   FROM oceanbase.gv$ob_plan_cache_plan_stat)
WHERE query_sql LIKE '%in %(%'
  AND param_count > 200
ORDER BY param_count DESC LIMIT 5;

```

### 事后诊断

对查询进行 explain 观察 inlist 上是否存在 cast。如下案例中 16 行的 in 谓词中，inlist 中每个常量都存在一个 cast。当这个 inlist 长度逐步增加后，硬解析耗时会不断增加。

```shell
explain select * from t1 where c1 in ('1','2','3');
+--------------------------------------------------------------------------------------------------------------------------------------+
| Query Plan                                                                                                                           |
+--------------------------------------------------------------------------------------------------------------------------------------+
| ===================================================                                                                                  |
| |ID|OPERATOR        |NAME   |EST.ROWS|EST.TIME(us)|                                                                                  |
| ---------------------------------------------------                                                                                  |
| |0 |TABLE RANGE SCAN|t1(idx)|1       |17          |                                                                                  |
| ===================================================                                                                                  |
| Outputs & filters:                                                                                                                   |
| -------------------------------------                                                                                                |
|   0 - output([t1.c1], [t1.c2]), filter(nil), rowset=16                                                                               |
|       access([t1.__pk_increment], [t1.c1], [t1.c2]), partitions(p0)                                                                  |
|       is_index_back=true, is_global_index=false,                                                                                     |
|       range_key([t1.c1], [t1.__pk_increment]), range(1,MIN ; 1,MAX), (2,MIN ; 2,MAX), (3,MIN ; 3,MAX),                               |
|       range_cond([cast(t1.c1, DECIMAL(11, 0)) IN (cast('1', DECIMAL(1, -1)), cast('2', DECIMAL(1, -1)), cast('3', DECIMAL(1, -1)))]) |
+--------------------------------------------------------------------------------------------------------------------------------------+

```

## 问题原因

静态执行引擎需要保证 in 谓词左右两侧的类型是一致的，当类型不一致时，需要在解析阶段添加 cast。大量添加 cast 会导致硬解析整体的耗时和内存占用升高。

## 问题的风险及影响

SQL 硬解析耗时长，内存消耗高。

## 影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

## 影响版本

OceanBase 数据库企业版 V3.1.2 GA（oceanbase-3.1.2-20210618150922）之后版本、V3.2.2 GA（oceanbase-3.2.0-20211130225726）之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220419）、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）之后版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）之后版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）之后版本。

## 解决方法

1. 调整 SQL 写法，改变 in 谓词右值的数据类型，避免产生隐式 cast。
 2. OceanBase 数据库企业版 V4.2.x 系列升级至 V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之后版本；V4.3.x 系列升级至 V4.3.2（oceanbase-4.2.3.0-100000052024041220）及之后版本，并调整 `_inlist_rewrite_threshold` 的默认取值。

      - **MySQL MODE：** `ALTER SYSTEM SET _inlist_rewrite_threshold = 1000;`。
      - **Oracle MODE：** `ALTER SYSTEM SET '_inlist_rewrite_threshold' = 1000;`。

## 规避方式

无。

上一篇

[PX+UDF 函数+索引，PX 和索引并发，直接报事务 6220 错误或在报事务 6220 之后因超时时间过长反复重试，执行时间过长](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000513619)

下一篇

[分区表 local 索引排序的性能问题](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000233834) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线