这里有个处理指引，从这三个方向出发，依次排除。上面你已经排查过网络的问题，确认正常，可以重点分析一下 PD 或 TiDB 卡的问题。
- 网络慢了
- PD 卡了
- TiDB 卡了
网络慢了
首先立马查看 PD TSO RPC Duration，其正常数值范围 80% 差不多在 1ms 以内，99% 在 4ms 内，如果数值比较高，则说明网络和 PD 的处理时间长（包括 Go Runtime 调度和实际 TSO 处理逻辑），此时继续看 PD server TSO handle time + Client revc time 是否慢，如果不慢则说明 PD TSO 处理（和发送）不慢，大概率是网络问题，需要往网络问题方向排查。
PD 卡了
如果 PD server TSO handle time + Client revc time 慢：
- 如果是 v4.0.13 版本及以后，由于这个监控其实只包括了 PD leader 处理 TSO 时间，所以它慢说明 PD TSO 处理的慢，此时应该考察 PD Leader 的 CPU 占用情况是否较高？以及是否存在混布（混合部署）的情况，即同一台机器上有其他的进程或操作扰乱了 PD 的计算，影响了 TSO 的处理速度。
- 如果是 v4.0.13 版本之前（不包括），那么说明 PD leader 处理 TSO 时间慢或回传给客户端的发送时间慢或两者都比较慢，需要同时考虑上述 PD CPU 问题以及 PD 到 TiDB 之间的网络问题。
还有一个情况也会影响到 PD 的 TSO 分配——PD 出现了 leader 切换，不过一般出现 leader 切换，直接会导致 TSO 不可用，并不能是让 TSO 变慢的原因，只在此一提，仅供参考。
TiDB 卡了
如果顺利排除了网络问题和 PD 问题，那么疑点又回到了 TiDB 这边。由于 TSO 的后台处理流程和 TiDB 的 Parser 以及 Complie 生成 Plan 是同时进行的，遇到高强度的 Workload 和一些较为复杂的查询时，可能会消耗大量的资源，影响到 Wait 操作（里面使用了 select 语句以及 channel，涉及到 Go 的调度），此时可以来到 TiDB 的 Execution 监控面板，看看 Parse，Complie 和 Execute 的耗时。