ob v4版本,表组配置后,执行计划不生效的问题

sbtest1\sbtest2\sbtest4在一个表组里,并且他们的日志流leader都在一个ob server上,但是为什么我下面的sql的执行计划还是分布式执行计划?

mysql> EXPLAIN EXTENDED select count(*) from sbtest1 t1, sbtest2 t2, sbtest3 t4 where
t1.id=t2.id and t1.id=t4.id and t1.k<>t2.k and t1.k<>t4.k;
±----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Query Plan |
±----------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ============================================================= |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| ------------------------------------------------------------- |
| |0 |SCALAR GROUP BY | |1 |188204 | |
| |1 |└─HASH JOIN | |99989 |186392 | |
| |2 | ├─PX COORDINATOR | |99995 |147159 | |
| |3 | │ └─EXCHANGE OUT DISTR |:EX10000|99995 |109081 | |
| |4 | │ └─MERGE JOIN | |99995 |23675 | |
| |5 | │ ├─TABLE FULL SCAN|t1 |100000 |5483 | |
| |6 | │ └─TABLE FULL SCAN|t2 |100000 |5483 | |
| |7 | └─TABLE FULL SCAN |t4 |100000 |5483 | |
| ============================================================= |

Outputs & filters:
0 - output([T_FUN_COUNT(*)(0x7f6b3cc28da0)]), filter(nil), rowset=256
group(nil), agg_func([T_FUN_COUNT(*)(0x7f6b3cc28da0)])
1 - output(nil), filter(nil), rowset=256
equal_conds([t1.id(0x7f6b3cc23500) = t4.id(0x7f6b3cc251c0)(0x7f6b3cc248f0)]), other_conds([t1.k(0x7f6b3cc26a30) != t4.k(0x7f6b3cc286f0)(0x7f6b3cc27e20)])
2 - output([t1.id(0x7f6b3cc23500)], [t1.k(0x7f6b3cc26a30)]), filter(nil), rowset=256
3 - output([t1.id(0x7f6b3cc23500)], [t1.k(0x7f6b3cc26a30)]), filter(nil), rowset=256
is_single, dop=1
4 - output([t1.id(0x7f6b3cc23500)], [t1.k(0x7f6b3cc26a30)]), filter(nil), rowset=256
equal_conds([t1.id(0x7f6b3cc23500) = t2.id(0x7f6b3cc23950)(0x7f6b3cc22c30)]), other_conds([t1.k(0x7f6b3cc26a30) != t2.k(0x7f6b3cc26e80)(0x7f6b3cc26160)])
merge_directions([ASC])
5 - output([t1.id(0x7f6b3cc23500)], [t1.k(0x7f6b3cc26a30)]), filter(nil), rowset=256
access([t1.id(0x7f6b3cc23500)], [t1.k(0x7f6b3cc26a30)]), partitions(p0)
is_index_back=false, is_global_index=false,
range_key([t1.id(0x7f6b3cc23500)]), range(MIN ; MAX)always true
6 - output([t2.id(0x7f6b3cc23950)], [t2.k(0x7f6b3cc26e80)]), filter(nil), rowset=256
access([t2.id(0x7f6b3cc23950)], [t2.k(0x7f6b3cc26e80)]), partitions(p0)
is_index_back=false, is_global_index=false,
range_key([t2.id(0x7f6b3cc23950)]), range(MIN ; MAX)always true
7 - output([t4.id(0x7f6b3cc251c0)], [t4.k(0x7f6b3cc286f0)]), filter(nil), rowset=256
access([t4.id(0x7f6b3cc251c0)], [t4.k(0x7f6b3cc286f0)]), partitions(p0)
is_index_back=false, is_global_index=false,
range_key([t4.id(0x7f6b3cc251c0)]), range(MIN ; MAX)always true
Used Hint:
-------------------------------------
/*+
*/
Qb name trace:
-------------------------------------
stmt_id:0, stmt_type:T_EXPLAIN
stmt_id:1, SEL$1
Outline Data:
-------------------------------------
/*+
BEGIN_OUTLINE_DATA
LEADING(@“SEL$1” ((“t1”@“SEL$1” “t2”@“SEL$1”) “t4”@“SEL$1”))
USE_HASH(@“SEL$1” “t4”@“SEL$1”)
PQ_DISTRIBUTE(@“SEL$1” “t4”@“SEL$1” LOCAL LOCAL)
USE_MERGE(@“SEL$1” “t2”@“SEL$1”)
FULL(@“SEL$1” “t1”@“SEL$1”)
FULL(@“SEL$1” “t2”@“SEL$1”)
FULL(@“SEL$1” “t4”@“SEL$1”)
OPTIMIZER_FEATURES_ENABLE(‘4.3.3.0’)
END_OUTLINE_DATA
*/
Optimization Info:
-------------------------------------
t1:
table_rows:100000
physical_range_rows:100000
logical_range_rows:100000
index_back_rows:0
output_rows:100000
table_dop:1
dop_method:Table DOP
avaiable_index_name:[k_1, sbtest1]
pruned_index_name:[k_1]
stats info:[version=2025-07-02 20:11:18.265391, is_locked=0, is_expired=0]
dynamic sampling level:0
estimation method:[OPTIMIZER STATISTICS, STORAGE]
t2:
table_rows:100000
physical_range_rows:100000
logical_range_rows:100000
index_back_rows:0
output_rows:100000
table_dop:1
dop_method:Table DOP
avaiable_index_name:[k_2, sbtest2]
pruned_index_name:[k_2]
stats info:[version=2025-07-18 22:00:03.252737, is_locked=0, is_expired=0]
dynamic sampling level:0
estimation method:[OPTIMIZER STATISTICS, STORAGE]
t4:
table_rows:100000
physical_range_rows:100000
logical_range_rows:100000
index_back_rows:0
output_rows:100000
table_dop:1
dop_method:Table DOP
avaiable_index_name:[k_3, sbtest3]
pruned_index_name:[k_3]
stats info:[version=2025-03-26 02:12:34.429561, is_locked=0, is_expired=0]
dynamic sampling level:0
estimation method:[OPTIMIZER STATISTICS, STORAGE]
Plan Type:
DISTRIBUTED
Note:
Degree of Parallelisim is 1 because of table property

±----------------------------------------------------------------------------------------------------------------------------------------------------------------+
104 rows in set (0.06 sec)

mysql>
【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

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

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

3 个赞

针对您的问题,这可能是由于分区分布不均或是表的分区策略设置不当导致的。为了更准确地定位问题,可以先通过 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’}”

请注意替换上述命令中的 -h127.0.0.1 -P2881 -utest@test -p****** -Dtest 为您实际的数据库连接信息,同时提供一个具体的 trace_id 用于跟踪问题。

此外,为了更好地帮助您解决问题,请您提供以下信息:

  1. 您的表 sbtest1、sbtest2 和 sbtest4 的创建语句是什么样的?特别是关于分区的设置部分。
  2. 当前的分区 Leader 分布情况是怎样的?可以使用 SHOW PARTITIONS FROM <table_name> 查看。
  3. 您尝试执行的 SQL 查询语句是什么?能否分享该查询的具体内容?
  4. 是否可以通过 EXPLAIN 命令查看到当前 SQL 的执行计划,如果是的话,可以提供一下 EXPLAIN 的输出结果吗?

这些信息将有助于我们更准确地分析问题所在,并给出合理的解决方案。

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

SHOW VARIABLES like ‘version_comment’;查一下 版本信息

1 个赞


看着sbtest3不在一个表组里

1 个赞

你好,你提的这个技术问题牵涉到OceanBase企业版范围内的功能细节;针对此类问题,建议你通过以下方式寻求帮助:

  1. 如你所在的企业客户已签署OceanBase企业版销售合同,请你联系客户经理;

  2. 如你所在的企业客户尚未签署OceanBase企业版销售合同,你可通过OceanBase官网商务咨询页面留下你的联系方式,OceanBase企业版的业务顾问会在一个工作日内与你联系。

另外,我们欢迎你使用社区版,并在论坛/社群中分享你对社区版本的想法、经验和问题,与其他社区成员共同交流。

看到了 谢谢

学习一下

集相关的日志和诊断信息