那可能不是gc没推进，而是你需要被gc的数据一直都很多啊。。。
建新表只能临时解决一段时间吧，再跑一段时间，不是又不行了。
看下执行计划，是卡在哪个地方，理论应该是下推取一行的
process_key跟total_key相差很大，历史版本太多了
1 个赞
你这是查指定字段，用select * limit 1 试试呀
SELECT * FROM table LIMIT 1;
我最近也在反复测试gc和compact，自动compact相当保守，一天也compact不了多少key ，手工compact效果不错，但是系统负载很高，非常消耗资源。
从官方手册分析，有这几个参数可能有用，我还没验证
你把表里的数据全部delete再查就很慢了
按照正常的算法，数据库在查找此表数据时，查找到任何一条数据就会立即返回结果，所以不应该慢。
简单说，一个表假设10亿个key（tidb按 key排序存储），第一行可以返回的数据在第5亿行，找到这行数据就要读5亿条数据，所以很慢
有个简单的测试，建个自增表，插入1亿条数据，删除前99999999条数据只留最后一条，然后select * from X limit 1，会扫描全部数据
这种场景，在生产上很常见，增删频率很高的表都有这种可能性存在
这表DML语句频繁吗？
1 个赞
一直在update
是的，而且目前我测试过，靠compact删除数据是非常非常慢的，把1亿条数据delete，会变成2亿个key，过一天也少不了一半
update语句执行速度快吗？
带条件，有主键或索引，速度应该很快。
走主键或索引可以定位数据在region里面位置，扫描的key数量数量会少
是的，这种情况很快