show variables like '' 这类的sql慢

为提高效率,请提供以下信息,问题描述清晰能够更快得到解决:

【TiDB 版本】
4.0.10
【问题描述】


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

1、这样的 慢 SQL 在所有的 tidb-server 上都有吗,建议根据 instance 看一下

观察了一下 是其中一台tidb

  1. 测试了一下,每次新建连接运行第一次会比较慢,应该是要从配置里读取,缓存到内存中,之后都会很快。
  2. 你的是每次新建连接都要show一下吗? 这个目的是什么? 又有什么影响呢? 哪种场景需要这样?

我测试是不新建连接 也会出现慢的情况。
还有问了下研发,他们是使用datagrip工具连接数据库

https://docs.pingcap.com/zh/tidb/v4.0/dashboard-profiling#tidb-dashboard-实例性能分析页面,可以参考这篇文章,抓取一下 火焰图

profiling_pack_3.zip (341.4 KB)

帮确认个信息,这个 tidb-server 查询 SESSION_VARIABLES 这个系统表的 表现如何,慢还是快?

另外,trace format=‘row’ set xxx 看看这个语句哪里慢

SHOW SESSION VARIABLES; 除了第一次会慢,其他不慢,是不是我的连接都是经常一次连接?

你的感觉应该都是一次链接,你可以开启general log 验证下。

我怎么定位是第一次连接呢?

日志里会详细记录session链接的时间,做了什么操作。 都可以看出来。

开启是否对性能有影响?

会有,验证的话,你可以在业务低峰期开启,验证后,尽快关闭。

每次都慢那可能哪里有问题
第一次慢的话,有可能的原因是,当时 tidb 的内存里面还没有加载 region 信息,首次查询需要从 pd 加载 tikv 的 region 信息并缓存。而且缓存是有有效期的,如果访问模式是,每隔好几个小时访问一次,然后就再也不访问了,那有可能每次重复这个过程,看上去就是每次 show variable like 都慢了

1赞

每次都慢,有可能有好多并发连接每次上来都读这个地方,每次请求都是到的同一个 region,
然后导致 tikv 形成读热点变慢的,这个假设需要大量的并发连接请求可能出现,可以查下使用的框架或者业务模式是怎么样的。

1赞