Coprocessor 执行耗时时间比较长

yulei7633 · 2023 年10 月 16 日 03:00

当执行一条SQL语句的时候，dashboard显示的慢查询时间与实际执行的时间不一致，如下图所示：

大概需要5秒
但是到dashboard上的slow查询同样一样sql语句的，时间缺显示11.5秒

不知道啥原因：
仔细分析sql语句执行的时间耗时：

有哪位大神帮分析一下原因？给好评，可以标记最佳答案。

yulei7633 · 2023 年10 月 16 日 03:05

时间超过11.5秒，是不是因为并行执行后，时间总和，因为我这个表是个分区表，128个分区。执行计划显示每个分区上都有需要统计的数据。

yulei7633 · 2023 年10 月 16 日 03:14

从慢查询表里面(slow_query)查询出来的时间的确是11.5秒。我手动执行的时间是5.10秒，慢查询表里面记录的是11.5秒，有点不太理解。

tidb菜鸟一只 · 2023 年10 月 16 日 03:16

你在客户端里面手工执行的时候是第一次执行吗？还是多次执行？可能是有缓存的。建议加上sql_no_cache试一下还慢吗？dashboard里面可能不是你手工执行的这条，而是应用里面的

yulei7633 · 2023 年10 月 16 日 03:19

目前是个测试环境，程序由我个人控制，当时测试的时候程序是没有生效语句的。手工执行的时候，执行过很多次，并不是第一次执行，dashboard里面的慢查询，的确是我刚手工执行的语句。

像风一样的男子 · 2023 年10 月 16 日 03:22

Coprocessor耗时是多个kv多线程并行执行的总时间会超过sql执行时间的。

yulei7633 · 2023 年10 月 16 日 03:22

这个我理解了。谢谢。

tidb菜鸟一只 · 2023 年10 月 16 日 03:23

你加上sql_no_cache试下每次的执行时间，同一个客户端每次执行只有第一次会慢一点，后面有了缓存都会快一点的

yulei7633 · 2023 年10 月 16 日 03:24

这个具体怎么加？能写一下吗？比如：select count(*) from t;

Fly-bird · 2023 年10 月 16 日 05:36

SELECT SQL_NO_CACHE count(1) FROM $table;

tidb菜鸟一只 · 2023 年10 月 16 日 06:22

select sql_no_cache count(*) from t;

yulei7633 · 2023 年10 月 16 日 06:24

收到，我测试一下。

yulei7633 · 2023 年10 月 16 日 06:26

mysql> SELECT sql_no_cache count(*) form_user_id FROM ffffffffffffffWHERE form_id = 1022161 AND STATUS = 1 AND MASTER = TRUE AND fid = 97253 OR ( 1 = 1 AND string_1 = “a” ) OR ( 1 = 1 AND ( 1 = 1 AND string_1 = “b” ) AND ( 1 =
1 AND double_3 > “5” ) ) LIMIT 0,1;
±-------------+
| form_user_id |
±-------------+
| 16412 |
±-------------+

加不加，效果一样的。

TiDBer_小阿飞 · 2023 年10 月 16 日 07:06

1.先用Explain Analyze + SQL跟踪一下时间分布，看看耗时在哪个算子上
2.Coprocessor累计执行耗时看起来大于SQL执行时间，这个是因为TiKV 会并行处理任务，因此累计执行耗时不是自然流逝时间
3.查看dashboard上的slow查询的基本信息页，查看 “使用的统计信息“是否是pseudo
4.如果是pseudo的统计信息，使用Analyze table xxxx 来重新收集下这个表的统计信息，然后重新执行查询 Explain Analyze + SQL，看下和未执行前 estRows行数有没有变化
5.修改参数：pseudo-estimate-ratio
这个参数代表修改的行数/表的总行数的比值，超过该值的时候，系统会认为统计信息已经过期，就会使用pseudo，这个值的默认值是0.8，最小值是0，最大值是1。它是统计信息是否失效的判断标准。
可以将这个参数调整成1，从而让TiKV执行SQL的时候不选择pseudo统计信息。