推荐还是先打散热点， 可以先看下监控 tikv-detail >> thread cpu 里面的 cpu 使用分布情况。

第一个意思应该是有读写权限，但是空间很小就会回退吧 就是如果没有权限 就会有问题。

这是 config，不是 variable。

https://docs.pingcap.com/zh/tidb/v7.5/tidb-configuration-file#temp-dir-从-v630-版本开始引入 这个。

新版本是 fast ddl，他需要 tidb-server 有一个好盘落文件。配置下 tmp-dir:https://docs.pingcap.com/zh/tidb/v7.5/tidb-distributed-execution-framework 没有好盘试试降级，把 fast ddl 直接关了吧。

低版本没有指定功能，所有和 pd 的交互都是 pd leader 支持服务的。 高版本有微服务，https://docs.pingcap.com/zh/tidb/stable/pd-microservices/ 但是是实验特性，不推荐使用。虽然能分压，但是实际上也完全是你想要的功能。

(tidb@172.16.201.18) [(none)]>set global tidb_enable_top_sql = 1; ERROR 1227 (42000): Access denied; you need (at least one of) the SUPER or SYSTEM_VARIABLES_ADMIN privilege(s) for this operation 看起来不行

浏览器版本是多少，试试更新比较新版本试试。 或者登录 dashboard 的账户是啥

[image] 用 pitr，别用这个。

官网没写错，我确认了下：这个参数是检查频率 + 超时阈值

那真的感觉是写应用挂了？应用没报错么。。。Orz

这个感觉是超时阈值吧。

当时连接什么的有掉 0 么？掉 0 的时候只有 insert 掉 0 么，如果不是那数据库应该没问题，因为数据库有问题应该都执行不了 看监控 tikv 、tidb 都是突然掉 0，感觉像前端压力突然没了。应用没啥报错么？对应时间。

1.关闭这个功能的话，使用 pd-ctl 删除 evict-slow-store-scheduler 即可 2.要降低敏感程度，调高这个也是个办法 raftstore.inspect-interval，减少 TiKV 侧检测 slow score 的频率

你要不试试将 239 23180 的 leader 手动驱逐一下，然后观察下

跑不出来的，可以试试 explain for connect + id 看看在执行的过程中的 sql 的执行计划。 https://docs.pingcap.com/zh/tidb/stable/sql-statement-explain#explain-for-connection

截图下这部分内容： [image]

pd 和 drainer 不要混合部署。

简单点 使用这个命令 手动执行下看看报错是啥呢