--- title: Runtime Filter 特性引入的估行不准计划走偏的原因和解决方法-OceanBase数据库使用指南 description: 了解OceanBase数据库在实际应用中关于 Runtime Filter 特性引入的估行不准计划走偏的原因和解决方法相关的常见问题和使用技巧，帮助您快速解决 Runtime Filter 特性引入的估行不准计划走偏的原因和解决方法的难题。 --- 切换语言 - 简体中文 - English 划线反馈 # Runtime Filter 特性引入的估行不准计划走偏的原因和解决方法 更新时间：2026-05-14 09:21 适用版本： V4.2.x、V4.3.x 内容类型：Troubleshoot ## 问题现象 某集群环境 MySQL 租户开启 Auto DOP 后 SQL 执行耗时 2300s+ 耗时较长，执行计划走偏，不开启 Auto DOP，全表扫描执行耗时 475s。 ## 关键诊断信息 1. 估算的行数和实际的行数差距大估行不准。 ![image](https://obbusiness-private.oss-cn-shanghai.aliyuncs.com/doc/img/knowledge-base/database/performance/20250609runtime-filter-feature-introduces-inaccurate-estimates-deviates-from-plan.png) 2. 计划开启了并行计划，并且启用了 `JOIN FILTER` 例如 `set global runtime_filter_type ='range,in,bloom_filter'`。 3. 执行计划中有算子 `JOIN FILTER CREATE` 和 `JOIN FILTER USE` 算子。 ```shell +-------------------------------------------------------------------------------+ | =========================================================================================================================================================================== |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|REAL.ROWS|REAL.TIME(us)|IO TIME(us)|CPU TIME(us)| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |0 |SCALAR GROUP BY | |1 |1425129 |1 |2189794044 |0 |9 | |1 |└─PX COORDINATOR | |8 |1425129 |8 |2189792985 |1951834284 |1952433625 | |2 | └─EXCHANGE OUT DISTR |:EX10003 |8 |1425127 |8 |2189743469 |0 |321 | |3 | └─MERGE GROUP BY | |8 |1425127 |8 |2189743469 |0 |289 | |4 | └─HASH JOIN | |2826278 |1418724 |108320 |2189743469 |0 |105068 | |5 | ├─JOIN FILTER CREATE |:RF0000 |2789519 |741334 |2936335 |383863 |0 |119336 | |6 | │ └─EXCHANGE IN DISTR | |2789519 |741334 |2936335 |349349 |80363 |210491 | |7 | │ └─EXCHANGE OUT DISTR (HASH) |:EX10000 |2789519 |522843 |2936335 |348150 |0 |1609 | |8 | │ └─PX BLOCK ITERATOR | |2789519 |32044 |2936335 |347092 |0 |656 | |9 | │ └─TABLE FULL SCAN |fem |2789519 |32044 |2936335 |347092 |0 |204426 | |10| └─EXCHANGE IN DISTR | |243 |514160 |354350 |2189743342 |1094377198 |2189216540 | |11| └─EXCHANGE OUT DISTR (HASH) |:EX10002 |243 |514136 |354350 |2189741428 |16866 |1461 | |12| └─MATERIAL | |243 |513707 |354350 |2189740368 |0 |746472 | |13| └─NESTED-LOOP ANTI JOIN | |243 |513707 |354350 |2189645060 |0 |13174592 | |14| ├─NESTED-LOOP JOIN | |243 |464913 |354350 |2189645060 |0 |51627019 | |15| │ ├─EXCHANGE IN DISTR | |795 |419799 |2577629 |2189645060 |12325 |199731 | |16| │ │ └─EXCHANGE OUT DISTR (BC2HOST)|:EX10001 |795 |418978 |2577629 |2122487454 |2115799962 |3874 | |17| │ │ └─JOIN FILTER USE |:RF0000 |795 |418747 |2577629 |2122487454 |0 |2503 | |18| │ │ └─PX BLOCK ITERATOR | |795 |418747 |2577629 |2122487454 |0 |4199 | |19| │ │ └─TABLE FULL SCAN |prd |795 |418747 |2577629 |2122487454 |0 |3236126 | |20| │ └─TABLE RANGE SCAN |cust(idx_amm_acc_rlvnc_1) |1 |57 |354350 |2189645060 |0 |1416798700 | |21| └─SUBPLAN SCAN |VIEW1 |1 |201 |0 |2189741428 |0 |96416 | |22| └─DISTRIBUTED TABLE RANGE SCAN |dpe_busssign_reg(IDX_DPE_BUSSSIGN_REG_1_UNQ)|1 |201 |0 |2189741428 |0 |467686129 | =========================================================================================================================================================================== ``` 4. 参与连接的表连接的字段有多列并且 `NDV` 比较极端，`INR_CUST_ACCT` 的 `NDV` 和行数接近，`SUB_ACCT_SEQ_NO` 的 `NDV` 很小。 ```shell prd.INR_CUST_ACCT prd.SUB_ACCT_SEQ_NO prd : rows: 54491958.000000 statis type: OPTIMIZER version: 1715868185639904 used partitions: [-1] INR_CUST_ACCT : NDV: 48099991.000000 Null: 0.000000 hist scale: -1.000000 Min: __OB__MIN__ Max: __OB__MAX__ SUB_ACCT_SEQ_NO : NDV: 4037.000000 Null: 0.000000 hist scale: -1.000000 Min: __OB__MIN__ Max: __OB__MAX__ ``` 优化器追踪 optimizer trace log 的获取方法。 ```shell step1: proxy”保持“会话 SET TRANSACTION ISOLATION LEVEL READ COMMITTED; step2: 开启当前session的优化器追踪功能 call dbms_xplan.enable_opt_trace(); step3: 设置追踪日志的level和日志文件后缀 call dbms_xplan.set_opt_trace_parameter(identifier=>'trace_test', `level`=>3); step4: 查询计划 explain select * from t1; step5: 在observer日志目录下查看trace_test为后缀的追踪日志 vi /home/admin/oceanbase/log/optimizer_trace_BkkGn1_trace_test.trac step6: 关闭优当前session的化器追踪功能 call dbms_xplan.disable_opt_trace(); ``` 如果命中了以上 4 条关键信息，大概就命中了此问题。 ## 问题原因 SQL 的并行的计划中参与 `JOIN` 表下压 `JOIN FILTER` 后，估行过低导致了两个 `NESTLOOP JOIN`，性能很差。分配这个 `JOIN FILTER` 时，计算出了很高的选择率，`JOIN FILTER` 选择率计算存在问题，这种场景使用多列计算 `JOIN FILTER` 选择率的并且 `NDV` 比较极端，得到了偏差较大的结果。（Runtime Filter 是一种用于优化 `Hash Join` 性能的技术，它可以通过减少 `Hash Join` 需要 Probe 的数据量来提高查询的效率） ## 问题的风险及影响 估算走错计划，客户业务执行耗时增加。 ## 适用版本 OceanBase 数据库 V4.2.x 及之后版本。 ## 解决方法 USE_HASH(TABLE_NAME) Hint 指定使用 HASH JOIN。 ## 规避方式 设置 `runtime_filter_type` 为空，关闭 `runtime filter`，命令如下。 ```shell set global runtime_filter_type =''; ``` Previous [专有云环境中 UPDATE 语句执行效率低下，影响业务运行的原因和解决方法](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000003699323) Next [自适应连接功能导致 SQL 执行报错 -4016](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000005908626) ![有帮助](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) 咨询热线