看日志报错 根据报错内容排查
看看gc时间，gc以后，再经过compact空间才会降低
你这脚本我研究了下，还是比较麻烦，需要确定region在哪个store上，否则执行会报错
root@tidb3:~# tiup ctl:v7.6.0 tikv --host 192.168.19.206:20160 compact -r 6865 -d kv -c default --threads 1 --bottommost force
Starting component ctl: /root/.tiup/components/ctl/v7.6.0/ctl tikv --host 192.168.19.206:20160 compact -r 6865 -d kv -c default --threads 1 --bottommost force
DebugClient::region_info: RpcFailure: 5-NOT_FOUND info for region 6865
Error: exit status 255
root@tidb3:~# tiup ctl:v7.6.0 tikv --host 192.168.19.207:20161 compact -r 6865 -d kv -c default --threads 1 --bottommost force
Starting component ctl: /root/.tiup/components/ctl/v7.6.0/ctl tikv --host 192.168.19.207:20161 compact -r 6865 -d kv -c default --threads 1 --bottommost force
store:“192.168.19.207:20161” compact_region db:Kv cf:default range:[[122, 116, 128, 0, 0, 0, 0, 0, 4, 255, 83, 0, 0, 0, 0, 0, 0, 0, 248], [122, 116, 128, 0, 0, 0, 0, 0, 4, 255, 83, 95, 114, 128, 0, 0, 0, 0, 255, 14, 166, 1, 0, 0, 0, 0, 0, 250]) success!
这个版本多半是bug
1 个赞
需要compact
这是我测试过的，集群级别的 compact，–threads=32你可以调到最低减少影响
tiup ctl:v7.5.0 tikv --pd 10.10.10.210:2379 compact-cluster -d kv --bottommost force -c write --threads=32
tiup ctl:v7.5.0 tikv --pd 10.10.10.210:2379 compact-cluster -d kv --bottommost force -c default --threads=32
1 个赞
大规模的数据删除还是不建议用delete来做，MVCC机制带来的GC对系统的压力很大的。
怎么删除数据呢？
需要手动compact
如果表剩余的数据量远小于删除的数据量，建议创建一个中间表的方式来删除，然后rename表，最后drop掉旧表，我们目前就是这么干的
2 个赞
楼下的解决方案非常棒!
楼下就是说我喽 
我建议删表吧，然后重建一张表
seiang大V是你的小号？
头一次见说楼下解决方案的，这是会预知未来啊~
根据我的测试，tidb是压缩的并且分布在多个tikv上，delete后compact能减少sst文件大小，但是具体看压缩比，压缩比高的省不了太多空空间
1 个赞
你仔细想想，仔细品一品，楼下是哪个楼下。
compact的时候，会受到MVCC机制的影响吗？
竟然觉得你说的有道理
MVCC机制和gc有关，delete的数据gc前可以通过mvcc查到，gc后mvcc查不到。
数据gc后会通知rocksdb数据被删除，然后在后面compact时候才会清理
MVCC机制执行Delete并不是直接删除数据 Tidb需要手动compact才会释放物理空间 类比Oracle删除数据后表空间也不会下降 需要手工shrink才会回缩表空间 释放物理空间