【 TiDB 使用环境】测试
【 TiDB 版本】7.1
【遇到的问题：问题现象及影响】
测试tidb gc回收情况，数据准备约9000万表的表
测试方式，循环删除，每次删除5000条，持续执行
删除语句：
delete from history_uint limit 5000;
测试结论：
越删除越慢，开始200毫秒左右一次，后面2秒以上
遇到问题：
删除半小时后，监控看后面gc任务就看不到了，cpu和io负载也大幅降低，不知道哪里有问题
补充1小时的gc，看起来后面没再进行gc
因为有 mvcc ，这个 SQL 越来越慢应该预期的。可以开 cop cache 来降低历史版本影响。
而且这个测试感觉没啥意义 
。情况表一般用 truncate。如果 delete 新版本推荐用 batch dml
batch dml也是循环delete，并没有什么不同
建议看下batch dml的原理，机制不一样。batch dml通过主键删除，跳过打gc标记的记录，删除性能稳定不会越来越慢。
因为没有GC，随着delete进行,数据是越来越多的（底层的delete不是删除数据，而是将数据标记为垃圾数据，在GC时才回清理），所以region数量不停在涨。GC卡住的原因，看一下GC时间设置，以及是否有其他的事物堵塞了GC。
gc设置10m，数据库测试就我一个人用
SELECT * FROM mysql.tidb;
贴一下结果
你这显示gc已经推进到最新时间了，如果系统负载高确实有可能gc推进不动，这里的gc时间会显示延迟的
1、 delete也是insert，删除数据是写入一条delete标记的新记录，所以delete会增加实际数据大小
2、 gc in compaction filter ，再compaction 时处理GC。
考虑在删除操作中以更大的批次进行删除，而不是每次只删除5000条数据。减少删除操作的次数可能会减少 GC 的负担，并提高删除操作的整体性能
删除官方文档最佳实践例子是5000，你认为多少合适
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。
