系统变慢，找不到原因

[enjoyit_jyc (Hacker Fo Jca Br V)]

为提高效率，提问时请提供以下信息，问题描述清晰可优先响应。

• 【TiDB 版本】：Release Version: v3.0.5
• 【问题描述】：

两个服务器做的集群，64核 128G内存

问题1：一个简单的按主键查询的语句在navicat执行时快时慢，单表查询，0.02秒----2秒不等，目前系统也是这种现象，400万数据量，10次中有3次很慢

问题2：系统产生很多primary_lock，不知道系统变慢是否跟这个有关系，已经mok找到表，正在优化

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

[QBin (Bin)]

1. 可以通过 slowlog 对该语句进行分析，看看慢在哪一块，慢日志解读。另外也可以通过 trace 看看执行时间长的时候的结果。
2. 日志中的 lock primary lock 是读写冲突引起的。可以通过 mok 找到具体的表，这个读写冲突会引起 SQL 的 backoff ，也是 SQL 执行变慢的原因之一。
3. 监控这边的时间拖得太长了，可以针对性的把时间聚焦到问题性能慢的一个小时。暂时监控看到 PD TSO Duration 在 4.8 出现一个比较高的延迟，可以检查当时 TiDB TSO 相关的监控看下是 PD 慢还是 TIDB 内部慢。 另外 load schema duration 这边在 4.5 ~ 4.7 之间也是出现异常。可以排查一下是否 TiKV 这边变慢引起的，另外也可以排查一下该事件段内 TiDB 以及 TiKV 的日志是和否存在异常。

[enjoyit_jyc (Hacker Fo Jca Br V)]

好的，日志我在看看
刚才trace了一下 执行同一条语句 next 变化比较大

[QBin (Bin)]

1. 按照列到的点都排查一下。包括 慢日志以及这个 SQL 的 explain analyze 的结果。
2. 另外如果冲突表不是这个查询的表。应该就不是 backoff 引起的问题。需要进一步根据监控排查。
3. 这个是最上层 Next 意思是 TiDB 解析完之后执行到返回结果的时间 。