Oceanbase 4.3.5 bp2 SQL的执行计划感觉有点异常

[AntTech_ZUHSV7]

【 使用环境 】测试环境
【 OB or 其他组件 】Oceanbase 4.3.5 bp2 hf1
【 使用版本 】4.3.5.2-102010012025052715
【问题描述】
从MySQL尝试迁移至Oceanbase，该SQL，在MySQL的执行时间仅仅为1s，而ob则耗时100s，
从执行计划看有点奇怪。

==========================================================================================================================
|ID|OPERATOR                          |NAME                                                        |EST.ROWS|EST.TIME(us)|
--------------------------------------------------------------------------------------------------------------------------
|0 |SCALAR GROUP BY                   |                                                            |1       |68983       |
|1 |└─NESTED-LOOP SEMI JOIN           |                                                            |1       |68983       |
|2 |  ├─NESTED-LOOP OUTER JOIN        |                                                            |1       |55745       |
|3 |  │ ├─NESTED-LOOP JOIN CARTESIAN  |                                                            |1       |55718       |
|4 |  │ │ ├─TABLE GET                 |zj                                                          |1       |5           |
|5 |  │ │ └─NESTED-LOOP JOIN          |                                                            |1       |55713       |
|6 |  │ │   ├─NESTED-LOOP JOIN        |                                                            |12      |55532       |
|7 |  │ │   │ ├─NESTED-LOOP SEMI JOIN |                                                            |10      |55384       |
|8 |  │ │   │ │ ├─HASH JOIN           |                                                            |118     |53180       |
|9 |  │ │   │ │ │ ├─TABLE FULL SCAN   |kh                                                          |1276    |48867       |
|10|  │ │   │ │ │ └─NESTED-LOOP JOIN  |                                                            |3151    |2964        |
|11|  │ │   │ │ │   ├─TABLE RANGE SCAN|yh(idx_ftsp_zj_bmyh_2)                                      |44      |2191        |
|12|  │ │   │ │ │   └─TABLE RANGE SCAN|qzkhxx(idx_crm_kh_qzkh_private_17)                          |60      |16          |
|13|  │ │   │ │ └─SUBPLAN SCAN        |VIEW2                                                       |1       |18          |
|14|  │ │   │ │   └─TABLE RANGE SCAN  |ftsp_kh_qzkh_code_relation(idx_ftsp_kh_qzkh_code_relation_4)|1       |18          |
|15|  │ │   │ └─TABLE GET             |hzzt                                                        |1       |16          |
|16|  │ │   └─TABLE GET               |dqht                                                        |1       |16          |
|17|  │ └─TABLE RANGE SCAN            |khDate(idx_csp_kh_visit_date_1)                             |1       |27          |
|18|  └─SUBPLAN SCAN                  |VIEW1                                                       |1       |13238       |
|19|    └─HASH JOIN                   |                                                            |1       |13238       |
|20|      ├─TABLE RANGE SCAN          |wq(idx_ftsp_wq_fwsx_3)                                      |173     |18          |
|21|      └─MERGE JOIN                |                                                            |14      |13146       |
|22|        ├─SORT                    |                                                            |69      |5197        |
|23|        │ └─NESTED-LOOP JOIN      |                                                            |7142    |693         |
|24|        │   ├─TABLE GET           |khxx                                                        |1       |18          |
|25|        │   └─TABLE RANGE SCAN    |htxx(idx_ftsp_ht_htxx_13)                                   |14303   |318         |
|26|        └─TABLE FULL SCAN         |mx(idx_ftsp_ht_fwsxmx_1)                                    |339831  |7041        |
==========================================================================================================================

而原SQL这个地方是有关联条件的。

并且用的是主键。

MySQL则是正常地走主键。

不知道这里是否有什么异常。

【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

[论坛小助手]

推荐使用 obdiag 工具进行日志采集，以便我们确认问题所在。

日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

请将采集到的日志提供给我们以便进一步分析。另外，为了更好地帮助您解决问题，请您提供以下信息：

1. 是否可以提供具体的 SQL 语句？如果涉及敏感信息，是否可以对数据进行脱敏后提供？
2. OceanBase 数据库的执行计划（EXPLAIN）结果是否可以提供？
3. 是否可以提供 MySQL 和 OceanBase 的表结构对比（CREATE TABLE 语句）？
4. 当前 OceanBase 集群的配置参数中，是否有针对执行计划优化的相关设置（如 parallel_degree 等）？
5. 是否可以提供 trace_id 或者具体的执行时间范围，以便更精准地定位问题？

附上敏捷诊断工具 obdiag 使用帮助链接

[AntTech_ZUHSV7]

我们配置一下：set optimizer_dynamic_sampling=0;

发现，执行时间变成：4s

虽然仍比MySQL慢，但是可接受。

[try_again]

set optimizer_dynamic_sampling=0; 说明关闭了动态采样，优化器使用默认统计信息。看起来还有优化空间
1、数据迁移至ob后，建议手动发起集群合并：
执行合并-V4.3.5-文档-分布式数据库使用文档
2、收集统计信息：
手动收集统计信息-V4.3.5-OceanBase 数据库文档-分布式数据库使用文档
完成1、2步后可以再查询一次，看下耗时和执行计划，理论上会更优。

[淇铭]

可以使用obdiag收集一下信息
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

[ygb]

可以使用obdiag收集一下信息
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h127.0.0.1 -P2881 -utest@test -p****** -Dtest’, trace_id=‘Yxx’}”

[shigp]

学习中