这文件没有，你扩容的时候有问题吧，你用 tiup cluser reload xxx --skip-restart -R tiflash 刷新下 tiflash 的配置文件，应该也会刷新这文件

占不了多少，tidb 组件是 go 代码写的，一个连接是一个协程，所以也没法从操作系统层面看，你想看的话，自己写个脚本，连上 10000 个连接，观察下进程涨多少内存估算下

mvcc 版本过多问题，看下 gc 配置以及 gc 是否正常，检查业务逻辑，是否有突然的大量数据删除还未到 gc 时间 另外 6.1 版本的 gc compaction filter 机制问题也会导致 mvcc 版本过多问题，关闭这个 gc compaction filter 或者升级到 v6.5.11 以上，参考：https://docs.pingcap.com/zh/tidb/stable/release-6.5.11#改进提升

不管表大小，正常情况下 limit 1 走 tikv 都不会很慢

预期现象，tiflash 组件 4g 太小，如果你真的表很小，也没有必要用 tiflash，tiflash 资源规划应该根据你的业务情况来做，另外 limit 1 这种 sql 不建议走 tiflash，走 tikv 也不会慢

去看下执行快的时候，执行计划这里走的是 merge join 吗

语句文本和执行计划呢，发出来看下

不需要安装

怎么回事呢？怎么会是下游的 safe-point 时间呢，除非你 pd 地址写错了吧

现在就支持创建前缀索引哦，你试试 create index idx_1 on t1(col1(10));

从日志看，你这个节点的数据损坏了，看看主机的能修复不，不能修复考虑直接强制删除该节点（在能保证多数派的情况下）。

压力大，正常 SQL 吗，正常 SQL 代表你计算资源不够，如果不是正常 SQL ，先优化 SQL

把参数 check-requirements = false 设置上就行了，另外你 lightning 导入的表不要在 cdc 任务中，在任务中会导致数据不同步

dumpling linghtning 安装不麻烦，这工具拿过来直接用的，不用安装

看下 SQL，你这 1000 是怎么提交的 现在这效率很低，io 根本没有到瓶颈

就是 sql 执行的真实时间 等待可用资源的时间，资源组内 RU 被消耗完了 因为语句中算子执行有并行

没有用的，就算显示改了，也没有改的

从你的图上并不能直接看到 duration 升高与 lock resolve 有关，图中显示的 lock resolv ops 并不是很高啊，才十几，建议先分析对应时间点慢查询

GC 时间过了吗