ob执行计划里怎么判断是 索引全扫描及Cardinality问题?

1、ob执行计划里怎么判断是 索引全扫描indexfullscan
2、如何查看索引列的信息,show index 显示null
image

image

sql explain 一下, 很容易判断出是全表扫还是index 扫码

indexfullscan 不是 Index scan

explain object 是表名的话,就是主表扫描,否则会显示 表名(索引名)。

1 你是要知道索引的扫描范围 还是 索引的扫描方式。看下explain extended SQL 输出的range_key([test.id(0x7f08fae29290)]), range(1 ; MAX)

2 看下 information_schema.STATISTICS

Server version: 5.6.25 OceanBase 3.1.2
1、 可以说是扫描范围,indexfullscan 从头至尾扫描索引的数据,比如oracle的执行计划中有明显的indexfullscan 提示。 通过range 并不能判断是否是indexfullscan,比如使用日期做条件 range(1980-12-01 00:00:00.000000,MAX,MAX,MAX ; MAX,MAX,MAX,MAX)

2、回复的连接帖子里提到:
主表的统计信息用的是 __virtual_partition_meta_table 和 __all_virtual_column_statistic
存储层合并收集的统计信息在__all_column_statistic和__all_tenant_meta_table里。
优化器收集的统计信息在__all_table_stat,__all_column_stat, __all_histogram_stat里;

这里主表、存储层合并、优化器收集的统计信息都有什么作用? 有什么差异? SQL在生产执行计划是引用的是哪个层面的统计信息?

3、为测试统计信息往表里load了2800万数据,然后手动merge从昨天下午4点到今天早上看依然保持merging状态,merge process的值就没变化过

4、检查统计信息无相关数据,是否只有完全合并完成后才有相关统计信息?information_schema.STATISTICS记录的cardinality和show indexes一样 都是null。 为什么gv$table中记录的table_id和__all_table_v2等记录的完全不一样?

问题3:
目前是一个已知问题,详见issue:
https://github.com/oceanbase/oceanbase/issues/728

问题4:
_all_table_v2 表是对应的租户级别下查看,其中table_id是纯粹的table_id,
gv$table 表的table_id 里包含了tenant_id信息,可以通过如下的计算出纯粹的table_id,比如gv$table里对应的table_id是1234567890
select 1234567890 & (pow(2, 40) - 1);

问题1:
explain extended_noaddr xxx 输出中"range(MIN ; MAX)" 表示的就是index full scan
range_key([t2.id]), range(MIN ; MAX)

int类型可能有MIN MAX ,你看我给的例子里是组合索引,首列是个时间列,随便写了个时间,即便写0000-00-00 00:00:00 range也是指定的时间而不是MIN

测试没问题呢,麻烦提供一个测试的文本

加上 where mydate>‘0000-00-00 00:00:00’ 类似这样

这样已经不是index full scan了,可以在原生mysql上验证一下,应该是type=range.

感谢,第2个问题有啥详细说明没