oceanbase库建了一个时间字段的索引,where条件有时间范围但是没有走索引

【 使用环境 】生产环境
【 OB or 其他组件 】
【 使用版本 】5.7.25-OceanBase-v4.2.1.3
【问题描述】OB建立了一个字段名last_update_time 类型是 datetime on update current_timestamp。索引 idx_crm_member_points_1 类型Normal 字段last_update_time
【复现路径】使用 where 字段 between STR_TO_DATE(‘20250310 00:00:00’, ‘%Y%m%d %H:%i:%s’)
and STR_TO_DATE(‘20250310 23:59:59’, ‘%Y%m%d %H:%i:%s’)
和 where 字段 >=‘2025-03-10 00:00:00’
and 字段<=‘2025-03-10 23:59:59’
看执行计划都没有走索引

where 字段 >=‘20250310 00:00:00’
and 字段<=‘20250310 23:59:59’
看执行计划走索引了,但是没有数据。因为不符合时间格式

应该怎么样才能不用强制指定索引名称,时间能走索引。
备注:有些表是可以自动走索引的,但是部分表不能。
下面提供的是不能走的。

1、建表

CREATE TABLE crm (

id bigint(20) NOT NULL AUTO_INCREMENT ,

create_by varchar(30) DEFAULT NULL ,

create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ,

update_by varchar(30) DEFAULT NULL ,

update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ,

last_update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ,

m bigint(20) NOT NULL DEFAULT ‘0’,

s varchar(15) NOT NULL DEFAULT ‘’,

t varchar(10) NOT NULL ,

st varchar(15) DEFAULT NULL ,

c varchar(30) NOT NULL ,

sta varchar(10) NOT NULL ,

be datetime DEFAULT NULL,

en datetime DEFAULT NULL ,

PRIMARY KEY (id),

KEY idx_crm_1 (last_update_time) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_2 (s) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_3 (create_by) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_4 (m) BLOCK_SIZE 16384 LOCAL

) AUTO_INCREMENT = 1901843488069148675 AUTO_INCREMENT_MODE = ‘ORDER’ DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0

2、

explain extended

select *

from crm

where last_update_time between STR_TO_DATE(‘2025-03-17 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)

and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

执行计划

==========================================================

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|


|0 |TABLE FULL SCAN|crm|6205069 |8691094 |

==========================================================

Outputs & filters:


0 - output([crm.id(0x7f3e69e245a0)], [crm.create_by(0x7f3e69e24880)], [crm.create_time(0x7f3e69e24b60)], [crm.update_by(0x7f3e69e24e40)],

   [crm.update_time(0x7f3e69e25120)], [crm.last_update_time(0x7f3e69e23910)], [crm.m(0x7f3e69e25400)], [crm.s(0x7f3e69e256e0)],

   [crm.t(0x7f3e69e259c0)], [crm.st(0x7f3e69e25ca0)], [crm.c(0x7f3e69e25f80)], [crm.sta(0x7f3e69e26260)],

   [crm.be(0x7f3e69e26540)], [crm.en(0x7f3e69e26820)]), filter([crm.last_update_time(0x7f3e69e23910) >=

  STR_TO_DATE('2025-03-17 00:00:00', '%Y-%m-%d %H:%i:%s')(0x7f3e69e20440)(0x7f3e69e222c0)], [crm.last_update_time(0x7f3e69e23910) <= STR_TO_DATE('2025-03-18

  23:59:59', '%Y-%m-%d %H:%i:%s')(0x7f3e69e211c0)(0x7f3e69e229c0)]), rowset=256

  access([crm.id(0x7f3e69e245a0)], [crm.last_update_time(0x7f3e69e23910)], [crm.create_by(0x7f3e69e24880)], [crm.create_time(0x7f3e69e24b60)],

   [crm.update_by(0x7f3e69e24e40)], [crm.update_time(0x7f3e69e25120)], [crm.m(0x7f3e69e25400)], [crm.s(0x7f3e69e256e0)],

   [crm.t(0x7f3e69e259c0)], [crm.st(0x7f3e69e25ca0)], [crm.c(0x7f3e69e25f80)], [crm.sta(0x7f3e69e26260)],

   [crm.be(0x7f3e69e26540)], [crm.en(0x7f3e69e26820)]), partitions(p0)

  is_index_back=false, is_global_index=false, filter_before_indexback[false,false],

  range_key([crm.id(0x7f3e69e245a0)]), 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

  OPTIMIZER_FEATURES_ENABLE('4.2.1.0')

  END_OUTLINE_DATA

*/

Optimization Info:


crm:

  table_rows:225268914

  physical_range_rows:224847532

  logical_range_rows:215560740

  index_back_rows:0

  output_rows:0

  table_dop:1

  dop_method:Table DOP

  avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

  pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

  stats version:1741021861651651

  dynamic sampling level:0

Plan Type:

  LOCAL

Note:

  Degree of Parallelisim is 1 because of table property

1、发一下show create table table_name\G;
2、explain extended sql 保存到文本里 提供一下
3、 收集SQL性能问题信息

–根据时间和执行语句查询trace_id
select query_sql,svr_ip,TRACE_ID,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT
WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%select%’;

obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”

https://www.oceanbase.com/docs/common-obdiag-cn-1000000002488185

这张表有多少数据?查询结果有多少数据?发一下完整的sql呗

1 个赞

索引字段上有运算可能会导致不走索引

1、建表

CREATE TABLE crm (

id bigint(20) NOT NULL AUTO_INCREMENT ,

create_by varchar(30) DEFAULT NULL ,

create_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ,

update_by varchar(30) DEFAULT NULL ,

update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ,

last_update_time datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP ,

m bigint(20) NOT NULL DEFAULT ‘0’,

s varchar(15) NOT NULL DEFAULT ‘’,

t varchar(10) NOT NULL ,

st varchar(15) DEFAULT NULL ,

c varchar(30) NOT NULL ,

sta varchar(10) NOT NULL ,

be datetime DEFAULT NULL,

en datetime DEFAULT NULL ,

PRIMARY KEY (id),

KEY idx_crm_1 (last_update_time) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_2 (s) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_3 (create_by) BLOCK_SIZE 16384 LOCAL,

KEY idx_crm_4 (m) BLOCK_SIZE 16384 LOCAL

) AUTO_INCREMENT = 1901843488069148675 AUTO_INCREMENT_MODE = ‘ORDER’ DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = ‘zstd_1.3.8’ REPLICA_NUM = 3 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0

2、

explain extended

select *

from crm

where last_update_time between STR_TO_DATE(‘2025-03-17 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)

and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

执行计划

==========================================================

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|


|0 |TABLE FULL SCAN|crm|6205069 |8691094 |

==========================================================

Outputs & filters:


0 - output([crm.id(0x7f3e69e245a0)], [crm.create_by(0x7f3e69e24880)], [crm.create_time(0x7f3e69e24b60)], [crm.update_by(0x7f3e69e24e40)],

   [crm.update_time(0x7f3e69e25120)], [crm.last_update_time(0x7f3e69e23910)], [crm.m(0x7f3e69e25400)], [crm.s(0x7f3e69e256e0)],

   [crm.t(0x7f3e69e259c0)], [crm.st(0x7f3e69e25ca0)], [crm.c(0x7f3e69e25f80)], [crm.sta(0x7f3e69e26260)],

   [crm.be(0x7f3e69e26540)], [crm.en(0x7f3e69e26820)]), filter([crm.last_update_time(0x7f3e69e23910) >=

  STR_TO_DATE('2025-03-17 00:00:00', '%Y-%m-%d %H:%i:%s')(0x7f3e69e20440)(0x7f3e69e222c0)], [crm.last_update_time(0x7f3e69e23910) <= STR_TO_DATE('2025-03-18

  23:59:59', '%Y-%m-%d %H:%i:%s')(0x7f3e69e211c0)(0x7f3e69e229c0)]), rowset=256

  access([crm.id(0x7f3e69e245a0)], [crm.last_update_time(0x7f3e69e23910)], [crm.create_by(0x7f3e69e24880)], [crm.create_time(0x7f3e69e24b60)],

   [crm.update_by(0x7f3e69e24e40)], [crm.update_time(0x7f3e69e25120)], [crm.m(0x7f3e69e25400)], [crm.s(0x7f3e69e256e0)],

   [crm.t(0x7f3e69e259c0)], [crm.st(0x7f3e69e25ca0)], [crm.c(0x7f3e69e25f80)], [crm.sta(0x7f3e69e26260)],

   [crm.be(0x7f3e69e26540)], [crm.en(0x7f3e69e26820)]), partitions(p0)

  is_index_back=false, is_global_index=false, filter_before_indexback[false,false],

  range_key([crm.id(0x7f3e69e245a0)]), 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

  OPTIMIZER_FEATURES_ENABLE('4.2.1.0')

  END_OUTLINE_DATA

*/

Optimization Info:


crm:

  table_rows:225268914

  physical_range_rows:224847532

  logical_range_rows:215560740

  index_back_rows:0

  output_rows:0

  table_dop:1

  dop_method:Table DOP

  avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

  pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

  stats version:1741021861651651

  dynamic sampling level:0

Plan Type:

  LOCAL

Note:

  Degree of Parallelisim is 1 because of table property

你好,我也尝试其他的表,表都差不多的,where last_update_time between STR_TO_DATE(‘20250310 00:00:00’, ‘%Y%m%d %H:%i:%s’)
and STR_TO_DATE(‘20250310 23:59:59’, ‘%Y%m%d %H:%i:%s’)
这种方式 是会自动走索引的,9千万数据,另一个2亿数据就没有。几百万的也不走。

你好,数据量是2亿。也会存在另外的表9千万会自动走索引。百万不会自动走索引
select * from crm where last_update_time between STR_TO_DATE(‘20250310 00:00:00’, ‘%Y%m%d %H:%i:%s’)
and STR_TO_DATE(‘20250310 23:59:59’, ‘%Y%m%d %H:%i:%s’)

你查一下 这个信息
select * from oceanbase.DBA_OB_TABLE_STAT_STALE_INFO where table_name = ‘crm’;

select sql_id, PLAN_ID,query_sql,svr_ip,trace_id,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT
WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%select * from crm where%’;
obdiag sql性能收集
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”

https://www.oceanbase.com/docs/common-obdiag-cn-1000000002488185

1、

2、第二个查不了。提示没有表。

3、我查了一下,如果 last_update_time 区间里的数据超过一定数据就不会走索引而会全部扫描。相同的表,不同天数据量少是可以走索引的。是否有这样的限制,限制是多少。

1、查一下 走索引的last_update_time区间的count数据有多少 不走索引的区间数据有多少 截图发一下

粘贴过去注意转义字符 肯定可以执行 查询的结果报存在文本里 发一下
2、select sql_id, PLAN_ID,query_sql,svr_ip,trace_id,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%select * from crm where%’\G;

1、几十万条,
explain extended
select *
from crm
where last_update_time between STR_TO_DATE(‘2025-03-17 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-17 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)
image
image

奇怪如果是count的话都是走索引
(1)explain extended select count(*)
from crm
where last_update_time between STR_TO_DATE(‘2025-03-18 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

image
image

(2)
explain extended
select *
from crm
where last_update_time between STR_TO_DATE(‘2025-03-18 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

image

2、字符的已经换了,是说找到不到表
image

你查的库有问题 我看你是在crm库下查的这个GV$OB_SQL_AUDIT表 这个GV$OB_SQL_AUDIT表在oceanbase库下

1、你查询的信息 不是count的情况下 数据少的时候 走索引 数据多的时候 不走索引是吧
2、你把走索引的执行计划和不走索引的执行计划 保存在文本里 提供一下
3、select sql_id, PLAN_ID,query_sql,svr_ip,trace_id,client_ip,TENANT_NAME,user_name,DB_NAME,ELAPSED_TIME,RET_CODE,FROM_UNIXTIME(ROUND(REQUEST_TIME/1000/1000),’%Y-%m-%d %H:%i:%S’) from GV$OB_SQL_AUDIT WHERE REQUEST_TIME>=‘2024-04-05 14:34:00’ and lower(query_sql) like ‘%select * from crm where%’\G;

obdiag sql性能收集(走索引和不走索引都收集一下) 根据上面语句查询的trace_id
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”

https://www.oceanbase.com/docs/common-obdiag-cn-1000000002488185
4、crm表的数据一直有变化么

5、hint绑定索引执行
explain extended select /*+index(crm idx_crm_1) */ *
from crm
where last_update_time between STR_TO_DATE(‘2025-03-18 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

1、是的。
2、走索引

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|


|0 |TABLE RANGE SCAN|crm(idx_crm_1)|246036 |1141447 |

==================================================================================

Outputs & filters:


0 - output([crm.id(0x7f324fc245a0)], [crm.create_by(0x7f324fc24880)], [crm.create_time(0x7f324fc24b60)], [crm.update_by(0x7f324fc24e40)],

   [crm.update_time(0x7f324fc25120)], [crm.last_update_time(0x7f324fc23910)], [crm.m(0x7f324fc25400)], [crm.s(0x7f324fc256e0)],

   [crm.t(0x7f324fc259c0)], [crm.st(0x7f324fc25ca0)], [crm.c(0x7f324fc25f80)], [crm.sta(0x7f324fc26260)],

   [crm.begin_time(0x7f324fc26540)], [crm.end_time(0x7f324fc26820)]), filter(nil), rowset=256

  access([crm.id(0x7f324fc245a0)], [crm.last_update_time(0x7f324fc23910)], [crm.create_by(0x7f324fc24880)], [crm.create_time(0x7f324fc24b60)],

   [crm.update_by(0x7f324fc24e40)], [crm.update_time(0x7f324fc25120)], [crm.m(0x7f324fc25400)], [crm.s(0x7f324fc256e0)],

   [crm.t(0x7f324fc259c0)], [crm.st(0x7f324fc25ca0)], [crm.c(0x7f324fc25f80)], [crm.sta(0x7f324fc26260)],

   [crm.begin_time(0x7f324fc26540)], [crm.end_time(0x7f324fc26820)]), partitions(p0)

  is_index_back=true, is_global_index=false,

  range_key([crm.last_update_time(0x7f324fc23910)], [crm.id(0x7f324fc245a0)]), range(2025-03-17 00:00:00.000000,MIN ; 2025-03-17

  23:59:59.000000,MAX),

  range_cond([crm.last_update_time(0x7f324fc23910) >= STR_TO_DATE('2025-03-17 00:00:00', '%Y-%m-%d %H:%i:%s')(0x7f324fc20440)(0x7f324fc222c0)],

   [crm.last_update_time(0x7f324fc23910) <= STR_TO_DATE('2025-03-17 23:59:59', '%Y-%m-%d %H:%i:%s')(0x7f324fc211c0)(0x7f324fc229c0)])

Used Hint:


/*+

*/

Qb name trace:


stmt_id:0, stmt_type:T_EXPLAIN

stmt_id:1, SEL$1

Outline Data:


/*+

  BEGIN_OUTLINE_DATA

  INDEX("crm"@"SEL$1" "idx_crm_1")

  OPTIMIZER_FEATURES_ENABLE('4.2.1.0')

  END_OUTLINE_DATA

*/

Optimization Info:


crm:

  table_rows:225268914

  physical_range_rows:323296

  logical_range_rows:246036

  index_back_rows:246036

  output_rows:246036

  table_dop:1

  dop_method:Table DOP

  avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

  pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

  stats version:1741021861651651

  dynamic sampling level:0

Plan Type:

  LOCAL

Note:

  Degree of Parallelisim is 1 because of table property

不走索引

==========================================================

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|


|0 |TABLE FULL SCAN|crm|7469358 |8802370 |

==========================================================

Outputs & filters:


0 - output([crm.id(0x7f42da2245a0)], [crm.create_by(0x7f42da224880)], [crm.create_time(0x7f42da224b60)], [crm.update_by(0x7f42da224e40)],

   [crm.update_time(0x7f42da225120)], [crm.last_update_time(0x7f42da223910)], [crm.m(0x7f42da225400)], [crm.s(0x7f42da2256e0)],

   [crm.t(0x7f42da2259c0)], [crm.st(0x7f42da225ca0)], [crm.c(0x7f42da225f80)], [crm.status(0x7f42da226260)],

   [crm.begin_time(0x7f42da226540)], [crm.end_time(0x7f42da226820)]), filter([crm.last_update_time(0x7f42da223910) >=

  STR_TO_DATE('2025-03-18 00:00:00', '%Y-%m-%d %H:%i:%s')(0x7f42da220440)(0x7f42da2222c0)], [crm.last_update_time(0x7f42da223910) <= STR_TO_DATE('2025-03-18

  23:59:59', '%Y-%m-%d %H:%i:%s')(0x7f42da2211c0)(0x7f42da2229c0)]), rowset=256

  access([crm.id(0x7f42da2245a0)], [crm.last_update_time(0x7f42da223910)], [crm.create_by(0x7f42da224880)], [crm.create_time(0x7f42da224b60)],

   [crm.update_by(0x7f42da224e40)], [crm.update_time(0x7f42da225120)], [crm.m(0x7f42da225400)], [crm.s(0x7f42da2256e0)],

   [crm.t(0x7f42da2259c0)], [crm.st(0x7f42da225ca0)], [crm.c(0x7f42da225f80)], [crm.status(0x7f42da226260)],

   [crm.begin_time(0x7f42da226540)], [crm.end_time(0x7f42da226820)]), partitions(p0)

  is_index_back=false, is_global_index=false, filter_before_indexback[false,false],

  range_key([crm.id(0x7f42da2245a0)]), 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

  FULL("crm"@"SEL$1")

  OPTIMIZER_FEATURES_ENABLE('4.2.1.0')

  END_OUTLINE_DATA

*/

Optimization Info:


crm:

  table_rows:225268914

  physical_range_rows:227895186

  logical_range_rows:215565131

  index_back_rows:0

  output_rows:0

  table_dop:1

  dop_method:Table DOP

  avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

  pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

  stats version:1741021861651651

  dynamic sampling level:0

Plan Type:

  LOCAL

Note:

  Degree of Parallelisim is 1 because of table property

3、没有权限。

4、是的。

5、可以 hint绑定索引执行,但是写死索引会不会有问题。

1、执行的语句+执行计划 保存在文本里

2、先看看执行计划 查看的执行计划保存在文本里

无法提供文件,本地文件都是加密的。
(1)走索引
sql:select *
from crm
where last_update_time between STR_TO_DATE(‘2025-03-17 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-17 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

执行计划:

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|

|0 |TABLE RANGE SCAN|crm(idx_crm_1)|246036 |1141447 |

==================================================================================

Outputs & filters:

0 - output([crm.id(0x7f324fc245a0)], [crm.create_by(0x7f324fc24880)], [crm.create_time(0x7f324fc24b60)], [crm.update_by(0x7f324fc24e40)],

   [crm.update_time(0x7f324fc25120)], [crm.last_update_time(0x7f324fc23910)], [crm.m(0x7f324fc25400)], [crm.s(0x7f324fc256e0)],

   [crm.t(0x7f324fc259c0)], [crm.st(0x7f324fc25ca0)], [crm.c(0x7f324fc25f80)], [crm.sta(0x7f324fc26260)],

   [crm.begin_time(0x7f324fc26540)], [crm.end_time(0x7f324fc26820)]), filter(nil), rowset=256

  access([crm.id(0x7f324fc245a0)], [crm.last_update_time(0x7f324fc23910)], [crm.create_by(0x7f324fc24880)], [crm.create_time(0x7f324fc24b60)],

   [crm.update_by(0x7f324fc24e40)], [crm.update_time(0x7f324fc25120)], [crm.m(0x7f324fc25400)], [crm.s(0x7f324fc256e0)],

   [crm.t(0x7f324fc259c0)], [crm.st(0x7f324fc25ca0)], [crm.c(0x7f324fc25f80)], [crm.sta(0x7f324fc26260)],

   [crm.begin_time(0x7f324fc26540)], [crm.end_time(0x7f324fc26820)]), partitions(p0)

  is_index_back=true, is_global_index=false,

  range_key([crm.last_update_time(0x7f324fc23910)], [crm.id(0x7f324fc245a0)]), range(2025-03-17 00:00:00.000000,MIN ; 2025-03-17

  23:59:59.000000,MAX),

  range_cond([crm.last_update_time(0x7f324fc23910) >= STR_TO_DATE('2025-03-17 00:00:00', '%Y-%m-%d %H:%i:%s')(0x7f324fc20440)(0x7f324fc222c0)],

   [crm.last_update_time(0x7f324fc23910) <= STR_TO_DATE('2025-03-17 23:59:59', '%Y-%m-%d %H:%i:%s')(0x7f324fc211c0)(0x7f324fc229c0)])

Used Hint:

/*+

*/

Qb name trace:

stmt_id:0, stmt_type:T_EXPLAIN

stmt_id:1, SEL$1

Outline Data:

/*+

  BEGIN_OUTLINE_DATA

  INDEX("crm"@"SEL$1" "idx_crm_1")

  OPTIMIZER_FEATURES_ENABLE('4.2.1.0')

  END_OUTLINE_DATA

*/

Optimization Info:

crm:

  table_rows:225268914

  physical_range_rows:323296

  logical_range_rows:246036

  index_back_rows:246036

  output_rows:246036

  table_dop:1

  dop_method:Table DOP

  avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

  pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

  stats version:1741021861651651

  dynamic sampling level:0

Plan Type:

  LOCAL

Note:

  Degree of Parallelisim is 1 because of table property

(2)不走索引

sql:
select *
from crm
where last_update_time between STR_TO_DATE(‘2025-03-18 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)
and STR_TO_DATE(‘2025-03-18 23:59:59’, ‘%Y-%m-%d %H:%i:%s’)

执行计划:

==========================================================

|ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)|

|0 |TABLE FULL SCAN|crm|7469358 |8802370 |

==========================================================

Outputs & filters:

0 - output([crm.id(0x7f42da2245a0)], [crm.create_by(0x7f42da224880)], [crm.create_time(0x7f42da224b60)], [crm.update_by(0x7f42da224e40)],

[crm.update_time(0x7f42da225120)], [crm.last_update_time(0x7f42da223910)], [crm.m(0x7f42da225400)], [crm.s(0x7f42da2256e0)],

[crm.t(0x7f42da2259c0)], [crm.st(0x7f42da225ca0)], [crm.c(0x7f42da225f80)], [crm.status(0x7f42da226260)],

[crm.begin_time(0x7f42da226540)], [crm.end_time(0x7f42da226820)]), filter([crm.last_update_time(0x7f42da223910) >=

STR_TO_DATE(‘2025-03-18 00:00:00’, ‘%Y-%m-%d %H:%i:%s’)(0x7f42da220440)(0x7f42da2222c0)], [crm.last_update_time(0x7f42da223910) <= STR_TO_DATE('2025-03-18

23:59:59’, ‘%Y-%m-%d %H:%i:%s’)(0x7f42da2211c0)(0x7f42da2229c0)]), rowset=256

access([crm.id(0x7f42da2245a0)], [crm.last_update_time(0x7f42da223910)], [crm.create_by(0x7f42da224880)], [crm.create_time(0x7f42da224b60)],

[crm.update_by(0x7f42da224e40)], [crm.update_time(0x7f42da225120)], [crm.m(0x7f42da225400)], [crm.s(0x7f42da2256e0)],

[crm.t(0x7f42da2259c0)], [crm.st(0x7f42da225ca0)], [crm.c(0x7f42da225f80)], [crm.status(0x7f42da226260)],

[crm.begin_time(0x7f42da226540)], [crm.end_time(0x7f42da226820)]), partitions(p0)

is_index_back=false, is_global_index=false, filter_before_indexback[false,false],

range_key([crm.id(0x7f42da2245a0)]), 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

FULL(“crm”@“SEL$1”)

OPTIMIZER_FEATURES_ENABLE(‘4.2.1.0’)

END_OUTLINE_DATA


*/

Optimization Info:

crm:

table_rows:225268914

physical_range_rows:227895186

logical_range_rows:215565131

index_back_rows:0

output_rows:0

table_dop:1

dop_method:Table DOP

avaiable_index_name:[idx_crm_1, idx_crm_2, idx_crm_3, idx_crm_4, crm]

pruned_index_name:[idx_crm_2, idx_crm_3, idx_crm_4]

stats version:1741021861651651

dynamic sampling level:0


Plan Type:

LOCAL


Note:

Degree of Parallelisim is 1 because of table property

感觉是 如果你这个时间范围内数据量太大, 优化器评估回表的代价大于全表扫描的代价,所有走了全表扫描。 当范围小的时候, 回标代价小于全表扫描所以走索引。

话说你们这个数据量,不根据时间字段建立分区吗

你好,应该是这样的优化逻辑。刚刚换的OB库还在熟悉阶段。这个是业务库,更新很频繁。按更新字段分区会不会有问题?

应该如上面同学说的,你的某天的数据差异较大(数据有倾斜),优化器评估全表扫描代价低于走索引。 可以吧18日的时间区间对半缩小来验证下是不是这个现象。

分区键的选择应该不管OB还是其他数据库都不建议用频繁更新的字段,不然数据要在不同的分区来回转,内部维护成本太高

1、目前从执行计划来看 数据倾斜造成的问题 正如@ 冲冲冲说的 你查询的是全部字段 也没有用上覆盖索引 所以回表的代价大于全表扫描的代价 所有走了全表扫描 当范围小的时候, 回标表代价小于全表扫描所以走索引。
2、可以考虑根据时间字段建立分区 频繁更新的字段不建议建索引