我记得5.3以前默认tidb_analyze_version是2（当时还是实验特性），导致出现了问题，然后当时的解决方案就是把统计信息都删除，然后调整tidb_analyze_version为1，再整库收集一下统计信息。可以看到下面的修复方案，也是把默认值改成了1。5.3以上版本是没有这些问题的（不记得具体的版本是啥了）。 [image]

读线程压力太大了，先尝试优化sql，然后看看能不能split region，分散到其他节点中

感谢我们 钛合金战队 所有人

你这个问题好像不太好回答，我感觉就像在问，该怎么防止自己生病一样 反正要性能高，就一定需要ssd硬盘和万兆网络。

还没发布吧，都没这方面的消息

在 [互助交流区]提问和回复好像是不涨积分的，还有签到可以获取积分，连续签到每天5积分

新手最开始的时候就根据文档和实操来获取经验，经验累计一些了可以尝试根据文档来回复问题，这样就可以获得积分了，等经验多了就可以开始写文章了，文章质量越高分越多。

你说的是对的，而且compaction 应该是不定时的，也不知道啥时候才会释放空间 [image]

key_skipped_count是还没有gc的mvcc版本数量，update和delete都会导致这个数量上升。如果sql执行之前有大量delete或者update那么这个值可能就是对的。 可以查看一下你设置的gc时间，如果长可以适当改小一点，这样mvcc就会降低很多，不会扫描过多无用的数据

drop影响不大的，drop了数据也不会立即清除，而是gc来清除数据。gc的话，你去看tikv的cpu就知道，gc woker cpu就一个线程，清除历史数据不回太快，所以这方面对业务无影响。 由于你删除的数据太大了，导致gc要执行很久，可能需要一周（没有根据随便猜的），这样会导致集群的gc被卡住无法正常推进（这个时候gc都在处理你drop的数据），drop语句执行之后的mvcc版本会累计下来，进而导致整个集群的mvcc版本变多，select的时候就会扫描更多的mvcc信息，可能会对业务产生一点影响

这个可以用文件的形式提供密钥，也就是把密钥写到文件中，让所有tikv节点都可以访问这个密钥文件就可以了。密钥文件路径在每个tikv中保持一致即可。

感觉可能是内存不够了，各个进程争抢内存，然后有的进程就触发了oom killer

有个配置项，默认超过300ms的sql都会被记录成慢sql，你可以根据实际情况去调整。

如果上面两位大佬说的都检查了没发现异常的话，再检查一下操作系统日志

武汉的吗

冲！！！

在dashboard里面查看一下热力图，看看是不是写热点了，如果是就用split region来分割region

你这有可能是有写热点了吧，create table的时候加了拆分region的参数吗，如果没有可以使用splite 来拆分现有的region，然后继续插入看看