这个测试出来结果为啥是全分区 有点搞不懂

【 使用环境 】测试环境
【 OB 】
【 使用版本 】
【问题描述】表t1是RANGE分区表,其DDL定义如下:
CREATE TABLE t1 (
C1INT,
C2 INT
PARTITION BY RAN GE(C1 + 1) (
PARTITION PO VALUES LESS THAN(100),
PARTITION P1 VALUES LESS THAN(200),
PARTITION P2 VALUES LESS THAN(MAXVALUE)
;SELECT * FROM T1 WHERI C1>= 199;该查询需要访问的分区情况是仅访问分区P2,但测出来是全分区 ?
【复现路径】问题出现前后相关操作
###创建t1表
create table t1 ( c1 int, c2 int ) partition by range(c1+1)( partition p0 values less than(100), partition p1 values less than(200), partition p2 values less than(maxvalue) );

##创建数据
DELIMITER //

CREATE PROCEDURE InsertTestData()
BEGIN
DECLARE i INT DEFAULT 1;

WHILE i <= 300 DO
    INSERT INTO t1 (c1, c2) VALUES (i, i * 2);
    SET i = i + 1;
END WHILE;

END //

DELIMITER ;

CALL InsertTestData();

##查看
select * from t1 where c1 >= 199;

##查看计划
SELECT DBMS_XPLAN.DISPLAY_CURSOR() ;
expalin select * from t1 where c1 >= 199;

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

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

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

4 个赞

根据您的描述,问题似乎与查询优化器的行为有关,可能是由于分区裁剪(Partition Pruning)未如预期工作导致的。这可能是因为表 t1 的分区键定义、查询条件、统计信息不准确或其他配置问题造成的。

建议您使用 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. 表 t1 的创建语句(包括索引和分区信息)。
  2. 执行计划的相关信息,例如通过 EXPLAIN 输出。
  3. 表 t1 的分区键定义是什么?
  4. 查询条件 c1 >= 199 中列 c1 的类型是什么?
  5. 表 t1 和列 c1 的统计信息是否是最新的?
  6. 当前使用的 OceanBase 版本是多少?

请您按照上面的命令执行日志采集,并将生成的日志文件提供给我们。如果可以的话,请也附上上述所需的信息,这将有助于我们更快地定位和解决问题。

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

2 个赞

分区键使用了表达式 c1 + 1,而查询条件使用的是原生列 c1 >= 199
按原理来说 OceanBase 优化器是不支持对 “表达式分区” 做反向条件推导的,所以无法执行分区裁剪,导致扫描全部分区。

4 个赞

说的太好了

1 个赞

mark~~

1 个赞

修改一下分区定义

1 个赞

优化器参数怎么配置