【TiDB 使用环境】生产环境
【TiDB 版本】7.5.4
【操作系统】Debian 12.9
【部署方式】云上部署（什么云）/机器部署（什么机器配置、什么硬盘）
【集群数据量】
【集群节点数】TiDB6/PD3/TiKV*4
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
慢日志中出现很多SELECT 1 的记录，机器负载也都不高， 这些SQL都是业务探活的SQL，不应该这么慢的。
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
TiDB Server 节点 CPU 资源怎么样？解析耗时高，一般是tidb-server资源紧张
1 个赞
查查有锁等待的sql吗
这个没看到哦
是不是太多以及并发太多？
慢日志产生有很多中，可以按照以下思路进行排查。
1、TiDB 连接池空闲连接超时。
2、TiDB Server 内部处理延迟，比如DDL语句。
3、TiDB 启用了 performance_schema 或其他监控功能，这也会造成SQL语句响应时间加长。
没有的 并发数没什么变化 但是偶尔会出现慢
以上的方式都排查过了，不太符合，没有ddl也没有新增performance_schema监控之类的。
这个可能不是慢在tidb，怀疑客户端响应慢。可以考虑在select 1慢的时间点在数据库里执行看看时间
看下监控中对应 tidb 节点 runtime 信息
trace select 1; 跟踪一下，看看哪里耗时
也抓包看了，客户端没有慢，尝试在server复现也没有复现出来，就是slowlog里边会记录，而且slowlog里边应该只是记录的server层执行的时间吧。
就11：45这个时间点，只有select 1，没有其他慢查询？
我看你trace的结果是飞快，所以这个select 1出现在慢查询里面的意思，应该是系统整体都慢，连select 1的速度都无法维持了。
类似的，如果系统整体很卡，p999的时间会突然往下掉。这个意思就是系统整体卡到，连p999也不足以评估和代表系统最慢的那一部分sql了。
而并不是select 1慢。
所以这种情况下，你抓着select 1分析，我感觉是没有结果的。
看runtime面板，里面有个关于go gc 的，叫STW的
看执行时间超过了 TiDB 的慢查询阈值，感觉可能是网络延迟所致，先着重排查一下网络质量。
你不用 盯着某一条看， 如果是小概率发生， 抓包也不一定能抓得到， 看下 sql statement 里面这条 select 1 的 sql 平均执行时间，中位数分别是多少？ 是不是只有很少量的 select 1 执行的慢
1 个赞