今天再次做了整理 ，瞬间变快了 ，还是不清楚原因 ，如果后期遇到此类问题还是不清楚从哪里入手
1 个赞
你在看下执行计划的total_keys量
1 个赞
楼上说的对，主要看执行计划
1 个赞
这种看执行计划貌似不好排查
1 个赞
这个表是不是经常大量加载和删除数据，只是现在表中没有数据？如果是这样的话，就存在伪删除的情况，TiDB需要便利整个表的store，所以时间很长。
耗时都在Coprocessor上，可以参照这部分排查 一般是tikv的cpu被占满了。 有些开发写的sql会占用tikv的cpu。
学习了学习了~
仔细看了下，GC 的机制就是这样，旧版本key的删除是需要等gc运作的时候才会删，所以可能他表中这么多的keys 都是历史待清理的key。 后来他第二次analyze 的时候，估计这些key已经被清理掉了，所以快了。
像这种问题，都可以先从执行计划开始看起。使用explain analyze可以看到真实的扫描keys数量，每一步的用时，使用算子情况等。然后看具体慢在哪一步上。这样就有针对性的解决问题了。
表被truncate后，analyze后，select还会扫描未来得及被GC的key吗？
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。