SQL查询速度很慢

背景信息

由于大表的原因,迁移到tidb进行测试,

TiDB 总体问题/TiDB 生态工具问题

TiDB 性能问题

TiDB-SQL 问题

1、sql 和 plan 如图 2、表结构 CREATE TABLE order ( id bigint(20) NOT NULL AUTO_INCREMENT, payment_order_id varchar(64) NOT NULL DEFAULT ‘’ COMMENT ‘’, merchant_id varchar(255) NOT NULL DEFAULT ‘’ COMMENT ‘’, merchant_name varchar(255) NOT NULL DEFAULT ‘’ COMMENT ‘’, out_trade_no varchar(64) NOT NULL DEFAULT ‘’ COMMENT ‘’, merchant_rate int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘’, merchant_fee int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘’, amount bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘’, pay_time timestamp NOT NULL DEFAULT ‘1970-01-01 08:00:01’ COMMENT ‘’, create_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, update_time timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY payment_order_id (payment_order_id), UNIQUE KEY mch_trade_no (merchant_id,out_trade_no), KEY out_trade_no (out_trade_no), KEY creat_time_index (create_time), KEY pay_time_index (pay_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin AUTO_INCREMENT=46318751 COMMENT=‘订单表’; 3、这个表数据量4000万

4、机器配置是 三台 4CPU 8G SSD500G TiBD1 - PD,TiKV TiBD2 - PD,TiKV,TiDB TiBD3 - PD,TiKV,TiDB

自己从执行结果上看,主要的耗时是在sum上,请问应该怎么优化

理论/原理性问题

保证问题描述清晰。

增加 merchannt_id,pay_time 联合索引试试,期待你的反馈

1赞

加了这个联合索引就好了。

请问我一下的理解是对的吗? 1、我的理解是,由于指命中了pay_time的索引,得出的结果集有412万,接着在这个数据量里面查找merchan_id=xx的时候,没有索引了,造成耗时很长 2、图中红框中的时间的意思,我自己理解是大部分的时间消耗在了IndexLookUp_15的这一环节,耗时超过了2分钟

1赞

如果觉得回答有用,可以将楼上的回答标记为解决方案噢 :grin:

1赞

好的,谢谢指点

不客气哒,有问题有分享都可以来 TUG 线上网站 :rose:

那我上面的疑问可以帮我解答一下吗

可以的呢,需要稍等片刻

好的,谢谢🙏

@datahoe 后续可以再帮忙解答一下吗

1、没错 2、也可以这么理解,你的执行计划首先通过IndexScan_11扫描到了索引pay_time的所有行,然后回表再根据列记录 merchannt_id过滤行,过滤时TiKV会有个HashAgg_7算子,将region里过滤到的记录求和之后发送给TiDB,就是你看到的IndexLookUp_15,这一步拿到的过滤的行时786,但实际上这里的时间是等待全部TiKV处理完数据的总时长。

2赞

明白了,谢谢

明白了,很有用,谢谢~

一行 sql 语句也太不好看了。。