【 TiDB 使用环境】生产环境 /测试/ Poc
生产环境
【 TiDB 版本】
v5.1.2
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【 问题 1 】
key 在 gc 之后，但是还没 compcat 之前，sql 查找时还需要扫描这些 keys 吗？还是直接跳过这些 keys ？如果跳过大概是如何做到的或者是什么原理？
【 问题 2 】
可以通过如下接口查找行的多版本数据，但是这个数据无法区分是gc后的还是未被gc的，因为只有gc+compcat之后，通过这个接口查出来的多版本数据才会彻底消失
curl http://192.168.1.1:10080/mvcc/key/dbname/table_name/343930187735040
是否有接口可以查找多版本数据是否已经被 gc 了？
【 问题 3 】
bug-11217: 多key GC调用导致GC不工作，大量历史版本残留
关于这个问题，我们采取的方法是 设置 gc.enable-compaction-filter: false 以关闭 TiKV 的 compaction filter GC，使用旧的 GC 模式进行多版本 GC
但是效果不太好，下面是一个具体例子
下面的sql是在11月29号执行的，使用覆盖索引查找100行数据，其中 create_time<=1669267277441 转化为时间之后是 create_time<=‘2022-11-24 13:21:17’
但是我们在11月23号就关闭了gc compaction filter 使用老的gc方式
desc analyze SELECT id FROM table_xxx FORCE INDEX(idx_essyncstate_bizproduct) WHERE (biz_id=300 AND es_sync_state=1 AND product_id=300 AND create_time<=1669267277441) ORDER BY create_time DESC LIMIT 100\G
*************************** 4. row ***************************
id: └─Limit_22
estRows: 4.12
actRows: 189
task: cop[tikv]
access object:
execution info: tikv_task:{proc max:485ms, min:70ms, p80:412ms, p95:456ms, iters:46, tasks:43}, scan_detail: {total_process_keys: 189, total_keys: 34711190, rocksdb: {delete_skipped_count: 610, key_skipped_count: 34712398, block: {cache_hit_count: 29983, read_count: 1866, read_byte: 38.9 MB}}}
operator info: offset:0, count:100
memory: N/A
disk: N/A
【 问题 4 】
show config where type=‘tikv’ and name like ‘%enable-compaction-filter%’;
set config tikv gc.enable-compaction-filter=false;
在 5.1.2 版本里面把这个参数关掉，是不是可以完全的解决 gc 的 bug ？会不会有其他的风险？(如果线上大量集群开启老的 gc 方式)
官方建议不要在线修改参数，那关闭新的gc方式建议使用tikv-ctl方式？
https://docs.pingcap.com/zh/tidb/v5.1/dynamic-config
【 问题 5 】
执行计划中的 delete_skipped_count 和 key_skipped_count 是什么意思？
这两个字段的解释在多个地方有多个不同的解释，但是还是不明白什么意思，可以帮忙解释一下吗，便于分析问题
版本 1
delete_skipped_count: 表示该 key 已经 gc ，状态为 tombstone ，还没有 compaction
key_skipped_count : 表示同一个 key 的 mvcc 版本比较多，没有过 GC 时间
版本 2
Rocksdb_delete_skipped_count：RocksDB 读数据过程中已删除 Key 的扫描数。
Rocksdb_key_skipped_count：RocksDB 扫数据时遇到的已删除 (tombstone) Key 数量。
版本3
在 asktug 上的帖子里
下面是一个测试
create table t123 (id int primary key,name varchar(100),age int,city varchar(100));
alter table t123 add index idx_name(name);
insert into t123 values (1,‘user1’,1,‘bj’);
insert into t123 values (2,‘user2’,2,‘bj’);
insert into t123 values (3,‘user3’,3,‘bj’);
insert into t123 values (4,‘user4’,4,‘bj’);
insert into t123 values (5,‘user5’,5,‘bj’);
insert into t123 values (6,‘user6’,6,‘bj’);
insert into t123 values (7,‘user7’,7,‘bj’);
insert into t123 values (8,‘user8’,8,‘bj’);
insert into t123 values (9,‘user9’,9,‘bj’);
insert into t123 values (10,‘user10’,10,‘bj’);
desc analyze select name from t123 where name=‘user1’\G
表中存在 1 行 name=‘user1’ 数据 ，没做过任何更新，删除操作，部分执行计划如下
scan_detail: {total_process_keys: 1, total_keys: 2, rocksdb: {delete_skipped_count: 1, key_skipped_count: 2
表中存在 3 行 name=‘user1’ 数据 ，没做过任何更新，删除操作，部分执行计划如下
scan_detail: {total_process_keys: 3, total_keys: 4, rocksdb: {delete_skipped_count: 3, key_skipped_count: 6
感谢各位大佬
【资源配置】
【附件：截图/日志/监控】