这两个数字有什么特殊含义么？
后面的数字就是region id 。
可以看到region id= 78757137 对应的sst文件就是这么多。
那扫描一次肯定时间长，难怪一扫到就是56s。
你先看看
可以通过这几个参数看到gc开了没开，间隔是多少。
看起来那个region很大，可以试试下面2个方法
1、 * 设置 gc.enable-compaction-filter: false 以关闭 TiKV 的 compaction filter GC，使用旧的 GC 模式进行多版本 GC，许要等待一段时间
2、手工compact tikv
tikv-ctl --host 10.172.65.156:20161 compact -c default -d kv --bottommost force
tikv-ctl --host 10.172.65.156:20161 compact -c write -d kv --bottommost force
如果有效的话，建议升级到最新的补丁版本
1 个赞
多谢大神，这个操作是每个kv 节点 都执行么？
另外，为了以防万一，这个命令的 rollback 语句该怎么写呢？
compact是每个tikv执行，没有回退 ，会消耗资源，建议低峰期
好的，我晚上进行操作，如果这个指令成功，（验证结果的话) 我是不是应该看到 region-properties -r 78757137 的 sst 文件变少？
另外，我有4个tikv，可以并行compat么？
会变少，可以4个一起执行
多谢大神，明天再来反馈结果
猫大神，关于gc的问题，我能做些什么fix一下吗？或者有什么途径trace一下其他线索？
我也是菜鸡 
你这个问题到了这，我是没有什么想法了。我看你gc参数也是10分钟一次，但是为啥不推进safe point，我一点思路也没有。
我翻了一遍文档也没有找到这方面的介绍。
呵呵，还是多谢，让我了解到我的gc的确是有问题的，而且 compat 的操作好像也应该是gc的活，感觉gc应该是这个case的根因
1 个赞
https://docs.pingcap.com/zh/tidb/stable/garbage-collection-configuration#tidb-50-引入的变化
从 TiDB 5.0 版本起，GC 仍然可以通过系统表 mysql.tidb 进行配置，但建议你使用系统变量进行配置，这样可以确保对配置的任何更改都能得到验证，防止造成异常行为
https://github.com/pingcap/tidb/issues/20655
我看了下这个对应的issue，意思是说gc可以通过set 来设置，也可以通过update mysql.tidb来设置。
但是直接更新这个表可能导致gc不运行。
你要不就重新通过set来设置一下这几个变量，看看是否能解决。
set不可以写错误值， mysql.tidb 可以设置错误值，导致数据库崩了
1 个赞
不触发gc的情况真的好稀少。
我翻了半天，基本都是上面这个情况，update mysql.tidb的时候参数格式是错的。
但这个情况在本问题中，应该是可以排除的，上面可以看到没有什么格式问题，还得其他大神来看看了。
https://github.com/tikv/client-go/wiki/Garbage-Collection
保底的方案：tikv client-go 文档里面直接给出了触发gc的样例代码，还说可以通过cron定期触发。
如果找不到其他原因的话，估计也就只有这样尝试一下了。 
建议升级下
感谢大神，前晚只是针对问题tikv节点做了次compat，大概2T多的数据，花费6个小时
compat完毕后，查看该问题region id，也没有sst文件了，（甚至这个region都回收了？)
再次执行explain analyze，也不在出现 大量xxxxx_skipped_count，返回也是秒出
trace 语句的执行，每个region返回时间也在预期
问题症状得到解决，非常感谢 h5n1大神
至于 gc的异常问题，我再开新帖请教吧
找机会升级吧
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。