【 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个并发查询,表里只有四条数据
Kongdom
(Kongdom)
2024 年10 月 14 日 03:09
2
执行用了多久? 出现了stats:pseudo执行analyze提升一下表健康度吧。
pseudo
状态表示统计信息不健康。
啦啦啦啦啦
2024 年10 月 14 日 03:13
3
dashboard看看慢的SQL具体是慢在哪个步骤了
Kongdom
(Kongdom)
2024 年10 月 14 日 03:32
5
默认是300ms以上是慢查询吧。还是先收集一下统计信息,提升表健康度吧。
舞动梦灵
(Ti D Ber Nckmz Hmh)
2024 年10 月 14 日 06:51
8
你看下他具体执行时间呀,默认是300毫秒,也就是0.3s就是慢查询会记录。如果不到1s的,这种sql完全可以忽略。
不能看到界面显示有慢查询就认为有问题。要看具体时间执行了多久,然后手动自己去执行一遍,看看要多久时间,
kevinsna
(Ti D Ber P O Zcnp Ja)
2024 年10 月 14 日 06:52
9
默认0.3秒是慢查询,可以看下dashboard中的慢日志,也可以看到SQL的具体执行时间
小龙虾爱大龙虾
(Minghao Ren)
2024 年10 月 14 日 12:07
10
分区表查询时没有加分区键,partition 走的 all,cop task 可能比较多
2 个赞
explain analzye 看下,我的测试环境10毫秒出结果。
zhanggame1
(Ti D Ber G I13ecx U)
2024 年10 月 15 日 09:22
13
做个analyze分析下吧,数据量小应该走全表扫描
分区表 的所有查询 都要用到分区键嘛, 我现在也是 表最新加了分区,然后我 有个 查询想请教一下 怎么建立索引 ,拿这个例子举例, SELECT * FROM users
WHERE username = ‘vi@AygXxRbgIrYS’ and auth
=1 and ak
=‘2121’ 应该建立一个什么样子的索引。感谢了
小龙虾爱大龙虾
(Minghao Ren)
2024 年10 月 18 日 03:15
15
TiDBer_w99XGHAd:
分区表 的所有查询 都要用到分区键嘛
是的,建议分区表涉及的 SQL 都要加上分区键,因为 TiDB 当前分区表上的索引都是本地分区索引,如果访问不加分区键的话,则会对所有索引分区进行扫描,执行计划中会出现关键字 partition:all(早期版本静态裁剪是 PartitionUnion 关键字),这样单个 sql 的 cop 请求数量就比较多了,sql 执行就比较慢了。
如果分区键是关联键的话,也可以走动态裁剪,但是表模型最好不要这样设计,参考:https://docs.pingcap.com/zh/tidb/stable/partitioned-table#动态裁剪模式
TiDBer_w99XGHAd:
应该建立一个什么样子的索引
这个场景应该建立 (username,ak) 这样的复合索引,分区键不用加到索引里是因为走了分区裁剪,直接扫对应分区,确定了这个 auth 值为 1 (实际上也不用建立索引,楼主说全表只有 4 行查询,走分区全扫就好了)
PS:分区表设计要结合业务特征,如果分区表使用不当,可能性能还不如非分区表
paulli
(Ti D Ber Nt O1w3 Ze)
2024 年10 月 20 日 01:39
18
能看下慢sql耗时阶段吗?网络延迟,磁盘io都有可能随着并发增大响应时间变长
1、表统计信息过期;
2、分区表查询没有使用分区键;
1,统计信息;
2,索引;
3,执行计划是否有很多版本,比如频繁删除数据等,需要想办法减少版本。
4,tiflash。