TiDB 3.0.x 慢查询日志不理解

🪐 TiDB 技术问题 性能调优
1

版本

3.0.11

image
image1505×398 36.2 KB

这个 sql 的执行时间，和 tikv 处理时间 与 等待时间 差这么多 要怎么理解

2
  1. 请问，每个指标你是怎么提取的，麻烦发下提取方法。
  2. 挑一个sql，找一下tidb slow log 里的具体信息，我们看下，多谢
3

我是查询的 慢日志， 上图是查询的结果

SELECT
	DATE_FORMAT( Time, '%Y年 %m月 %d日 %H:%i' ) AS '发生日期',
	Query_time AS '执行语句花费的时间(秒)',
	DB AS 'DB',
	`Query` AS 'SQL语句',
	Mem_max / 1024 / 1024 AS 'sql 使用的内存（MB）',
	Request_count AS 'Request_count [语句发送的 Coprocessor 请求的数量]',
	Process_keys AS 'Process Keys [Coprocessor 处理的 key 的数量, 数量越多越占用TiKV资源]',
	Process_time AS 'Process_time [SQL在TiKV的 处理时间之和(秒)]',
	Wait_time AS 'Wait_time [SQL在TiKV中, Coprocessor 请求排队等待时间之和(秒), ]',
	Backoff_time AS 'Backoff_time [语句遇到错误, 在重试前等待的时间(秒)]',
	CONCAT( `User`, '@', `HOST` ) AS '谁执行的',
	( CASE succ WHEN '1' THEN '成功' ELSE '失败' END ) AS '是否执行成功',
	Stats AS '统计信息时间戳, 是否显示为 pseudo' 
FROM
	information_schema.`slow_query` 
WHERE
	`is_internal` = FALSE
        AND time > DATE_SUB( NOW( ), INTERVAL 1 HOUR ) -- 查询最近一小时的
	
	ORDER BY
	Process_keys DESC,
	`Mem_max` DESC 
	LIMIT 1000;
4

可以看下解释， Process_time ：执行 SQL 在 TiKV 的处理时间之和，因为数据会并行的发到 TiKV 执行，这个值可能会超过 Query_time
https://pingcap.com/docs-cn/v3.0/how-to/maintain/identify-abnormal-queries/identify-slow-queries/#查询-slow_query-示例

5

1 即使超过是正确的，但是 执行时间 10秒， 处理之和100秒， 这也超太多了，为什么超这么多？没想明白

2 还有后面的等待之和，等待的时间，是不是也应该算这条SQL执行的总耗时时间？

3 Query_time 指的是什么时间，发送请求，到响应成功以后的时间吗？ 并不是实际的处理时间对吗？
如果我想通过 这sql 完成执行完以后在进行操作，我应该怎么办？

image
image1762×182 108 KB

6
  1. 比如说你有3个tikv，可能每个请求了30s，就是90s多。 不要把这两个很长的考虑为单个节点，他们是多个节点的时间之和。
  2. 是的要计算等待时间
  3. query time 就是这个sql发送到返回的时间。 这个和实际处理时间应该没区别吧。
    没明白这句话是什么意思？ --> 如果我想通过 这sql 完成执行完以后在进行操作，我应该怎么办
7

老师这里讲的 返回时间 ，我们参考如下图， 应该是在哪个阶段返回的

image
image1524×971 35.6 KB

image
image760×796 43.1 KB

image
image1292×752 34.2 KB

8

那这个 的query time 不应该是 30秒吗？ 为啥会是 10 秒呢

9
  1. tidb-server接受到sql信息，一直到tidb-server接受到返回结果。
  2. 你纠结的 coprocessor time 和 wait time，都是 tikv 内部多个 tikv 实例直接的时间之和，所以不需要这样考虑他们的时间超过了，你把tikv考虑为一个整体，接收到信息，返回信息给tidb，内部可能很多节点加起来有几十秒，但是整体返回只有几秒。
10

也就是说 这个等待时间之和，是指 这里面的 每个线程的等待时间 之和对吧
image

11

不是，tikv 这里coprocessor ，每个tikv都有，你的一个sql 可能要走多个tikv，所以理论上是分发的消息统一返回的时间。

12

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