好吧 直观来说后续还用这个系统的话，你可以试试升级系统内核。

delete_skipped_count: 2834812, key_skipped_count: 38806756 要不试试这个表手动收一下 compact：专栏 - TiDB MVCC 问题处理 | TiDB 社区

快应该是 copr_cache_hit_ratio 原因，cache 优化。 慢的话直观不预期，要么 mvcc compact 不及时，要么感觉是不是调整过一些算子大小，我看 cop task 有直接分253 个 task。或者是 tikv 很忙？

如果设计上不影响，我理解看下 ddl 为啥慢🤔。 可以先看下 admin show ddl jobs; 内容不。(或者看一下 information_schema.DDL_JOBS 表中内容)

swap 关了么？ 是否触发了 tmp 落盘。https://docs.pingcap.com/zh/tidb/stable/configure-memory-usage#数据落盘

看起来意思就是，a 表没有 tiflash 副本，truncate a 表的时候会发现 tiflash 做了相关 Applying partition changes 的操作的动作？怀疑 tiflash 可能影响 ddl 了。我确认下 tidb 是否有这个行为。 然后超时现象啥意思，因为我理解我们 ddl 是没有超时这个说法的。

业务在开启前会做 truncate partition 这个动作 是指什么： 创建 a 表，truncate a 表 alter table a set tiflash replica？ 还是说 a 表本身就配置过 tiflash replica，只是每次用 truncate 一次。 因为如果 a 表 tiflash 副本如果本身有，truncate 的话其实会保留属性。分区也是一个道理的。 然后 这步会超时退出 是指什么？是指 ddl 1 min 执行不完么？

这个是怎么感知到的？

可以搞个最小案例让咱们本地试试么？

是的，意思就是做下内存控制。 简单点你可以用 cgroup 来限制，也就是 resource_control：https://docs.pingcap.com/zh/tidb/stable/tiup-cluster-topology-reference

看你上文 top 内容，看起来你 tidb-server 和 tikv server 是混合部署的。 那么是否有做内存控制呢？ tikv 默认使用服务器内存 80% 以内。这部分内存是缓存的，你内存倾斜应该单纯就是有什么 sql 查这个节点数据比较多，数据从磁盘加载到内存了。这部分是缓存不会释放，减少 IO 的。 混合部署推荐做好内存控制

这个问题解决了么？

https://docs.pingcap.com/zh/tidb/stable/troubleshoot-lock-conflicts 要不要看看 data lock wait 一些内容啊？

额 锁等待不属于 backoff 吧。 是不是 delete + insert 内容有交叉导致的？

https://docs.pingcap.com/zh/tidb/stable/sql-plan-replayer 你要不上传一个 plan replayer 我瞅瞅。

没听说过这个计划。 而且行存模型不适合大规模分析查询，MPP 需要对列进行高效的处理，而 TiKV 的行存储不具备列存的优势（如压缩、向量化计算等）

新年快乐 刚看到最新有 1，还在想谁这么惨，大年初一遇到问题了来着。。

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

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