查询走索引速度比不走索引更慢

TiDB4.0版本,HDD,3TiKV,3TiDB/PD部署

有一个表,结构为:
CREATE TABLE quality_type (
id int(11) NOT NULL AUTO_INCREMENT,
vendor varchar(64) NOT NULL COMMENT ‘厂家名称’,
event_time timestamp NOT NULL COMMENT ‘统计时间’,
total bigint(20) NOT NULL COMMENT ‘小时数据量’,
update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP,
PRIMARY KEY (id),
KEY idx1 (vendor),
KEY idx2 (event_time)
)
数据分布如下:

2021-04-01 969640
2021-04-02 3355818
2021-04-04 2339989
2021-04-06 410525
2021-07-30 164
2021-07-29 26
2021-04-03 2562481
2021-04-05 1945786

分别测试了一条语句的3种写法



执行多次后发现,走TableFullScan的耗时平均只有0.3s左右,但是IndexRange的耗时在8s以上,能帮我分析一下其中的原因吗?


这个用了hash 聚合,不是下推计算,所以更慢了


我强制让它走streamAGG也不行呀

看起来它的耗时都是花费在下推TiKV做range过滤的时候

loops 太多次了,浪费资源 :sweat:

用合适的方法就行了

相信系统的自动优化选择器,会做出最优解,嘻嘻~

那很难判断什么是合适的方法。假如说我现在要把时间从0.3s降到0.1s,我之前的想法就是添加对event_time列的索引,但现在看这是行不通的;那对于这种情况而言,作为用户还能有其他的解决办法吗?(本身数据量也不是特别大,只有1400w)

只能通过 explain SQL 来判断那种最合适,貌似没别的办法 :rofl:

:thinking:好吧