TiDB集群联合查询慢

【 TiDB 使用环境】生产环境
【 TiDB 版本】 v6.1.0
【遇到的问题】 TiDB集群联合查询忽快忽慢
【复现路径】直接用sql查询
【问题现象及影响】
使用产单表查询时,响应正常:
SELECT infoid FROM push WHERE userid = 188902 ORDER BY id DESC LIMIT 5
使用联库联表查询时,响应在2秒~60秒
SELECT bsp.infoid,dfb.pname FROM base.push bsp
LEFT JOIN global.info dfb ON bsp.infoid=dfb.infoid
WHERE userid = 188902 AND dfb.toptype_code = ‘06’ ORDER BY bsp.date DESC LIMIT 5

库 base 表 push 数据量 13亿
CREATE TABLE push (
id bigint(20) NOT NULL AUTO_INCREMENT,
userid int(11) NOT NULL COMMENT ‘用户id’,
infoid varchar(255) COLLATE utf8mb4_general_ci NOT NULL COMMENT ‘记录id’,
keys varchar(255) COLLATE utf8mb4_general_ci DEFAULT NULL ,
date bigint(20) NOT NULL,
isvisit tinyint(4) DEFAULT NULL COMMENT ‘是否访问过;0:否 1:是’,
isv tinyint(4) DEFAULT NULL COMMENT,
type tinyint(4) DEFAULT NULL COMMENT,
PRIMARY KEY (id),
KEY userid (userid),
KEY date (date),
KEY infoid (infoid)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_general_ci

库 global 表 info 1.5亿
CREATE TABLE dws_f_bid_baseinfo (
id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
infoid varchar(32) NOT NULL COMMENT ‘数据id’,
a_code varchar(10) DEFAULT NULL ,
c_code varchar(10) DEFAULT NULL ,
d_code varchar(10) DEFAULT NULL’,
yx decimal(15,4) DEFAULT NULL,
zb decimal(15,4) DEFAULT NULL ,
zk decimal(10,4) DEFAULT NULL ,
names varchar(500) DEFAULT NULL ,
toptype_code varchar(15) DEFAULT NULL ,
s_code varchar(15) DEFAULT NULL ,
pn varchar(500) DEFAULT NULL ,
pc varchar(100) DEFAULT NULL ,
be_code varchar(15) DEFAULT NULL ,
ptime datetime DEFAULT NULL ,
ctime datetime NOT NULL ,
botime datetime DEFAULT NULL ,
isvf tinyint(1) NOT NULL DEFAULT ‘0’ ,
ps_id varchar(100) DEFAULT NULL,
d_id varchar(45) DEFAULT NULL,
u varchar(5000) DEFAULT NULL ,
p varchar(2000) DEFAULT NULL ,
mp tinyint(1) NOT NULL DEFAULT ‘0’ ,
s1 varchar(100) DEFAULT NULL ,
uptime datetime DEFAULT NULL ,
crtime datetime DEFAULT NULL ,
br_id varchar(32) DEFAULT NULL ,
ag_id varchar(32) DEFAULT NULL ,
PRIMARY KEY (id) /*T![clustered_index] NONCLUSTERED */,
KEY infoid (infoid)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin

【附件】
机器 8*32G kv存储为SSD盘

请提供各个组件的 version 信息,如 cdc/tikv,可通过执行 cdc version/tikv-server --version 获取。

关联查询的explain analyze结果上传下

现在db节点负载很大,cpu/内存一直处于 90% 以上

table:bsp, index:date(date) 这个索引走的不对,用SPM临时绑下吧,应该走userid那列索引, 先看下加hint后执行计划对不对,然后再绑
create global binding
for
SELECT bsp.infoid,dfb.pname FROM base.push bsp
LEFT JOIN global.info dfb ON bsp.infoid=dfb.infoid
WHERE userid = 188902 AND dfb.toptype_code = ‘06’ ORDER BY bsp.date DESC LIMIT 5
using
SELECT/+ use_index(bsp, userid)/ bsp.infoid,dfb.pname FROM base.push bsp
LEFT JOIN global.info dfb ON bsp.infoid=dfb.infoid
WHERE userid = 188902 AND dfb.toptype_code = ‘06’ ORDER BY bsp.date DESC LIMIT 5

好的,我试一下

学习学习了

试试上tiflash吧

嗯,现在这个规模数据的压力在tidb上还是tikv上? 通过扩容db节点有没有用?

tidb CPU利用率高还有影响的

现在有两个db节点,其中这个高占用的节点同时部署有PD、grafana、alertmanager,另外一个db节点只有db和PD,现在高再扩展出来一个db是不是也没啥帮助?

你前面说db cpu到90%了,先看看是不是还有sql能优化,如果没得可优化那可以扩

嗯,好的,非常感谢
集群部署上没有啥问题吧

老兄,去慢查询里面把执行快的和执行慢的explain analyze信息贴下,不然没信息什么都不知道呢?或者最起码贴个执行计划看看。

感谢,问题已经解决,由于数据量过大并发量高不适合做联表查询,做成宽表即可。

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