min 和limit 1无法查询出结果。

[sladenew]

【 TiDB 使用环境】生产环境
【 TiDB 版本】5.7.25-TiDB-v5.1.1 TiDB Server (Apache License 2.0) Community Edition, MySQL 5.7 compatible
【遇到的问题】
【复现路径】做过哪些操作出现的问题
【问题现象及影响】

表结构：

CREATE TABLE snapshot (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘主键’,
tag_id bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘tagid’,
tag_version bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘数据版本’,
PRIMARY KEY (id) /*T![clustered_index] CLUSTERED */
)

问题：
1.select min(id) from snapshot和SELECT * FROM snapshot limit 1 无法出结果。

2.但select max(id) from snapshot大概50毫秒出结果。

3.运行select min(id) from snapshot时，tikv-details-rocksdb-kv seek operations 中，next和next_found升高。

4.整个表数据量大约12亿条。

5.怀疑和gc是否有关？但最近2天没有做过数据删除操作，gc的配置：
±-----------------------±-------+
| Variable_name | Value |
±-----------------------±-------+
| tidb_gc_concurrency | -1 |
| tidb_gc_enable | ON |
| tidb_gc_life_time | 10m0s |
| tidb_gc_run_interval | 10m0s |
| tidb_gc_scan_lock_mode | LEGACY |
±-----------------------±-------+

【附件】

[h5n1]

@sladenew

select min(id) from snapshot和SELECT * FROM snapshot limit 1

这2个sql的explain看下

[sladenew]

select min(id)的explain

SELECT * FROM snapshot limit 1的explain

[h5n1]

min(id) 正常应该会转换成主键索引取top 1，得看下执行计划。 全表扫描limit 1不出结果可能是GC有问题导致表的历史版本没被清理。可以explain analyze 等着执行完看total_keys ,processed_keys间额差异

[sladenew]

1.现在遇到的问题就是在业务低峰执行10分钟以上也没有办法出结果，所以无法拿到total_keys ,processed_keys间额差异。
2.确实怀疑gc的问题，但数据这两天没有删除动作，gc时间也设置为10分钟。

[h5n1]

min那个SQL强制走主键看看执行计划。不是这2天删，是bug导致很久前的都没被清理，需要升级

TiDB Bug List=

bug-11217: 多key GC调用导致GC不工作，大量历史版本残留 影响版本 v5.0.0-v5.0.4 v5.1.0-v5.1.2 v5.2.0-v5.2.2 issue: https://github.com/tikv/tikv/issues/11217 TiKV GcKeys task doesn’t work when called with multiple keys (…

[sladenew]

1.FORCE_INDEX测试过，也无法出结果。
2.我先升级下版本，再测试下。