select * from T limit 1 执行很久

[Holland (Hacker Byb Hr4 Nu)]

【 TiDB 使用环境】生产环境
【 TiDB 版本】v6.5.1
【复现路径】做过哪些操作出现的问题
explain analyze SELECT * FROM label LIMIT 1; 执行很久，需要近2min

实际表的数据量看起来不大。

看了这个帖子专栏 - MVCC导致limit 1执行慢测试 | TiDB 社区

将gc由24h改成了30min，也没有效果，依旧很慢。但是加上有索引where 条件就很快返回。

【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】

[kkpeter (Upstream889)]

看着应该是同一个问题，但是看pr已经合并了，不知道是不是新版本又引入了

[kkpeter (Upstream889)]

看关联帖子，limit 1会扫全表，但是也没有排序是随机返回。 就不太理解这里TiDB扫全表的逻辑是啥，不如直接返回读到的第一条

[zhanggame1 (Ti D Ber G I13ecx U)]

数据量大不大你那么查没用，mvcc数据被忽略掉了，具体要看regions大小个数和keys数量，
可以这么查
select sum(t.APPROXIMATE_SIZE),sum(t.APPROXIMATE_KEYS) ,count(*) from INFORMATION_SCHEMA.TIKV_REGION_STATUS t
where t.DB_NAME=‘XX’ and t.TABLE_NAME=‘XXX’

[Holland (Hacker Byb Hr4 Nu)]

@zhanggame1

select sum(t.APPROXIMATE_SIZE),sum(t.APPROXIMATE_KEYS) ,count(*) from INFORMATION_SCHEMA.TIKV_REGION_STATUS t
where t.DB_NAME=‘XX’ and t.TABLE_NAME=‘XXX’

[zhanggame1 (Ti D Ber G I13ecx U)]

gc由24h改成了30min，你首先要确认gc是正常推进的。
然后gc并不能删除扫描的key数量，需要等数据库compact，可能会减少数据量和key，但是这个过程要很长时间

[Holland (Hacker Byb Hr4 Nu)]

看起来gc一直在推进

[zhanggame1 (Ti D Ber G I13ecx U)]

regions合计34G，全表扫描当然很慢。。gc时间你要改了没多久，再观察一两天看看吧

[Holland (Hacker Byb Hr4 Nu)]

好的，gc是前天晚上改的

[zhanggame1 (Ti D Ber G I13ecx U)]

数据量也不大，不如重建表了

[TIDB-Learner]

看着表不大， 直接 select * from table 多久？

[zhanggame1 (Ti D Ber G I13ecx U)]

聚簇表 limit1从头开始扫，扫到第一行返回，问题是扫到第一行可能要扫好多g数据

[路在何chu (Ti D Ber Ass Gn Qs R)]

这是偶尔的吧，其他表都是这样吗

[小龙虾爱大龙虾 (Minghao Ren)]

发执行计划

[Jellybean (李文杰)]

@Holland

【复现路径】做过哪些操作出现的问题
explain analyze SELECT * FROM label LIMIT 1; 执行很久，需要近2min

前面各位大佬聊的感觉没有到问题的核心，你把慢的SQL的执行计划贴出来，我们分析分析

[onlyacat]

也遇到过, 走错执行计划了， 要么加 hint 要么加 binding

[Kongdom]

确实，发一下执行计划吧，看着挺奇怪的

[有猫万事足]

tidb的执行计划是比较详尽的。
没有执行计划就只能靠经验和猜测。
缺少佐证的情况下，这些都只能是一种思路或者参考。

[春风十里 (Ti D Ber F Vf Ce7m B)]

SQL 慢的问题，还是看要细节，再分析，执行计划贴出来看看。

[zhanggame1 (Ti D Ber G I13ecx U)]

limit这么慢是正常的，他这个表数据量和region大小合计差几个数量级