show variables like '' 这类的sql慢

🪐 TiDB 技术问题 性能调优
1

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

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

%E5%9B%BE%E7%89%87
%E5%9B%BE%E7%89%871109×517 37 KB

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

2

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

3

观察了一下 是其中一台tidb

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

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

6

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

7

profiling_pack_3.zip (341.4 KB)

8

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

9

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

10

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

11

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

12

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

13

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

14

开启是否对性能有影响？

15

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

16

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

1 个赞
17

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

1 个赞