为何简单的查询会产生慢查询

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】


CREATE TABLE users (
_id bigint(0) NOT NULL AUTO_INCREMENT,
password varchar(255) DEFAULT NULL,
auth int(11) NOT NULL,
firstlogin tinyint(1) DEFAULT NULL,
sk varbinary(128) DEFAULT NULL,
ak varchar(20) DEFAULT NULL,
username varchar(64) DEFAULT NULL,
loginerrorcounts int(11) DEFAULT NULL,
loginlasttime bigint(110) DEFAULT NULL,
lastmodpasstime bigint(110) DEFAULT NULL,
token varchar(255) DEFAULT NULL,
defaultMgz varchar(255) DEFAULT NULL,
userdeleted tinyint(11) DEFAULT ‘0’,
active tinyint(11) DEFAULT ‘1’,
chklastlogintimeflag tinyint(11) DEFAULT NULL,
userloginchktime int(11) DEFAULT NULL,
PRIMARY KEY (_id,auth) /*T![clustered_index] CLUSTERED */,
KEY idx_users_ak (ak),
KEY idx_users_username (username)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=390001
PARTITION BY RANGE (auth)
(PARTITION p0 VALUES LESS THAN (0),
PARTITION p1 VALUES LESS THAN (1),
PARTITION p2 VALUES LESS THAN (2),
PARTITION p3 VALUES LESS THAN (3),
PARTITION p4 VALUES LESS THAN (4),
PARTITION p5 VALUES LESS THAN (5))

在执行SELECT * FROM users WHERE username = ‘vi@AygXxRbgIrYS’ LIMIT 1和SELECT * FROM users WHERE ak = ‘EzxWtqDeTS9wgKBl’ LIMIT 1时为什么会产生慢查询



查询时50个并发查询,表里只有四条数据

执行用了多久? 出现了stats:pseudo执行analyze提升一下表健康度吧。

pseudo 状态表示统计信息不健康。

dashboard看看慢的SQL具体是慢在哪个步骤了

二百零几毫秒

:thinking:默认是300ms以上是慢查询吧。还是先收集一下统计信息,提升表健康度吧。

具体多长时间?

这也不算慢查询吧

你看下他具体执行时间呀,默认是300毫秒,也就是0.3s就是慢查询会记录。如果不到1s的,这种sql完全可以忽略。
不能看到界面显示有慢查询就认为有问题。要看具体时间执行了多久,然后手动自己去执行一遍,看看要多久时间,

默认0.3秒是慢查询,可以看下dashboard中的慢日志,也可以看到SQL的具体执行时间

分区表查询时没有加分区键,partition 走的 all,cop task 可能比较多

2 个赞

也是噢,这个是分区表,没有使用到auth分区字段

explain analzye 看下,我的测试环境10毫秒出结果。

做个analyze分析下吧,数据量小应该走全表扫描

分区表 的所有查询 都要用到分区键嘛, 我现在也是 表最新加了分区,然后我 有个 查询想请教一下 怎么建立索引 ,拿这个例子举例, SELECT * FROM users WHERE username = ‘vi@AygXxRbgIrYS’ and auth=1 and ak =‘2121’ 应该建立一个什么样子的索引。感谢了

是的,建议分区表涉及的 SQL 都要加上分区键,因为 TiDB 当前分区表上的索引都是本地分区索引,如果访问不加分区键的话,则会对所有索引分区进行扫描,执行计划中会出现关键字 partition:all(早期版本静态裁剪是 PartitionUnion 关键字),这样单个 sql 的 cop 请求数量就比较多了,sql 执行就比较慢了。
如果分区键是关联键的话,也可以走动态裁剪,但是表模型最好不要这样设计,参考:https://docs.pingcap.com/zh/tidb/stable/partitioned-table#动态裁剪模式

这个场景应该建立 (username,ak) 这样的复合索引,分区键不用加到索引里是因为走了分区裁剪,直接扫对应分区,确定了这个 auth 值为 1 (实际上也不用建立索引,楼主说全表只有 4 行查询,走分区全扫就好了)

PS:分区表设计要结合业务特征,如果分区表使用不当,可能性能还不如非分区表

要看看具体执行计划耗时多在哪块。

能看下慢sql耗时阶段吗?网络延迟,磁盘io都有可能随着并发增大响应时间变长

1、表统计信息过期;
2、分区表查询没有使用分区键;

1,统计信息;
2,索引;
3,执行计划是否有很多版本,比如频繁删除数据等,需要想办法减少版本。
4,tiflash。

1、更新统计表的信息,重新执行看看吧