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 语句也太不好看了。。

此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。