【 TiDB 使用环境】生产环境
【 TiDB 版本】6.1.2
【复现路径】做过哪些操作出现的问题，上一个版本的集群是5.1.3，我们降低了tikv的配置，从16核32GB降低到了8核32G。以及把tikv升级到了6.1.2版本。
【遇到的问题：问题现象及影响】上一个版本5.1.3内存占比在缩减配置后，内存占比变的更高了，但是没有出现TiKV omm掉线重启的情况，后来我们看到官方新版本有对内存的优化，所以我们升级到了6.1.2版本，之后内存就一直95%，只要有大查询就会导致tikv omm掉线重启。
另外一个sql之前查询是没有问题的，但是最近在tikv不稳定的情况下，以及版本升级后，直接无法查询，不知道是不是sql的某个规则在新版取消导致的还是什么问题。
今天在正常业务服务期间，有比较高的qps，并且内存占比很高，由于业务需要，向集群中写入数据，导致tikv omm掉线，但是这次掉线后就无法自动重启。
【资源配置】
【附件：截图/日志/监控】
日志呢？
tikv的内存设置参数你们是怎么设置的？
所有的组件都升级到了 6.1.2 还是只有 tikv 升了其他没有升级？
经过这几天的排查和分析，也特别感谢tidb社群的朋友帮助，我把解决的过程记录下。
首先内存占比很高的问题，我们设置了内存参数就好了，内存占比就不会太高。
可以参考这个帖子：【线上运维之06】TIDB在线更改TIKV内存占比，解决频繁OOM问题 - 能胜的个人页面 - OSCHINA - 中文开源技术交流社区
tikv无法启动是因为顺坏了文件，有两种处理办法，一种是下线节点后重新添加，但是非常耗时，我们用的是这个方法，帖子的链接社群文档自行搜索下。
但是另外一种办法是找到损坏的文件并修复，通过 TiKV Control工具，打印损坏的 SST 文件信息，然后在通过修复工具修复或者忽略启动，我们没有尝试，所以具体操作顺序社群文档搜索。
[TiKV Control 使用说明]
(https://docs.pingcap.com/zh/tidb/dev/tikv-control#强制-region-从多副本失败状态恢复服务弃用)
问题3，sql查询失败，是因为我们一个用with写的sql的子查询不走索引，经过我们的排查，在自查询的 tabel 后面增加一行代码。FROM table_name FORCE INDEX (‘索引名’)，查询速度就恢复正常了，后来我们做了表分析，ANALYZE TABLE table_nam 发现不加强制索引也正常了。
最后查询速度也和tikv内部有没有错误有关，比如数据分布是否均匀等，性能都会有所提升。
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
