还是要看看执行计划吧
楼主解决了没有？
其实大家都想看一下执行计划，limit 1到底读取了多少行数据
1 个赞
发下执行计划看看，比较感兴趣
理论上不应该慢，如果慢就是TIDB算法问题了
理论上正常，而且很好复现，新建个表int自增主键，插入1亿条数据，然后只留最后一条（最大主键的）数据，再查limit 1就很慢了。或者这个表一条数据都没，那就更慢了
你把 explain analyze SELECT * FROM label LIMIT 1;结果贴出来啊，看看delete_skipped_count和key_skipped_count的结果是不是非常多，你说你改了gc时长，但是这个并不是一改立刻就能生效的，你可以反复执行 explain analyze SELECT * FROM label LIMIT 1;可以很明显看到delete_skipped_count和key_skipped_count的数据量应该会明显下降
我也发现反复执行会执行速度变快，反复执行delete_skipped_count和key_skipped_count下降是因为数据被缓存了吗？
跟缓存关系不大，delete_skipped_count和key_skipped_count代表的是你删除后的数据是否被gc和compact，如果还没gc或者compact，由于tidb的mvcc机制，他还是会扫到的，虽然不会返回，但是扫描这些数据也需要时间，当你gc或compact完成，这些垃圾数据不再扫描到的时候，查询就会变快了。。。
1 个赞
感觉不是这样，连续的反复执行语句，也会delete_skipped_count和key_skipped_count在变化的，gc和compact都有周期的，不会间隔这么短
以下是dashboard中的执行计划
id task estRows operator info actRows execution info memory disk
Limit_7 root 1 offset:0, count:1 1 time:1m55.7s, loops:2 N/A N/A
└─TableReader_11 root 1 data:Limit_10 1 time:1m55.7s, loops:1, cop_task: {num: 327, max: 722.6ms, min: 2.18ms, avg: 353.6ms, p95: 472.6ms, max_proc_keys: 1, p95_proc_keys: 0, tot_proc: 1m52.7s, tot_wait: 1.29s, rpc_num: 327, rpc_time: 1m55.6s, copr_cache_hit_ratio: 0.00, distsql_concurrency: 1} 636 Bytes N/A
└─Limit_10 cop[tikv] 1 offset:0, count:1 1 tikv_task:{proc max:690ms, min:1ms, avg: 345.3ms, p80:413ms, p95:450ms, iters:327, tasks:327}, scan_detail: {total_process_keys: 1, total_process_keys_size: 116, total_keys: 254783718, get_snapshot_time: 1.16s, rocksdb: {delete_skipped_count: 3025032, key_skipped_count: 257808423, block: {cache_hit_count: 4420, read_count: 383947, read_byte: 4.51 GB, read_time: 15.5s}}} N/A N/A
└─TableFullScan_9 cop[tikv] 1 table:t_label, keep order:false 1 tikv_task:{proc max:690ms, min:1ms, avg: 345.3ms, p80:413ms, p95:450ms, iters:327, tasks:327} N/A N/A
key_skipped_count: 257808423 毫不意外，还是上面的建议，最好是重建表了，create 新表把数据insert into select* from 插入,再renmae
之前版本测试有这个问题；试试7.5.
7.5都一样的，这是聚簇表的问题
因为你有LIMIT 1啊，这个sql的逻辑就是到所有的tikv节点扫描表对应region中的所有key，也包括未被gc和compact掉的，当然这部分会被过滤掉，然后所有的tikv都是一直过滤直到返回到实际需要的行数直接就结束了，这个其实返回的结果不一定每次都是同一个tikv先返回，扫到的所有key的数量肯定也不一样，但是你隔一段时间查一下，这个值的量级应该会整体下降的，毕竟你的gc肯定是在推进的。
gc改了有两天多了。delete_skipped_count和key_skipped_count的数量倒是增加了。
这是两天前的执行计划
id task estRows operator info actRows execution info memory disk
Limit_7 root 1 offset:0, count:1 1 time:1m55.7s, loops:2 N/A N/A
└─TableReader_11 root 1 data:Limit_10 1 time:1m55.7s, loops:1, cop_task: {num: 327, max: 722.6ms, min: 2.18ms, avg: 353.6ms, p95: 472.6ms, max_proc_keys: 1, p95_proc_keys: 0, tot_proc: 1m52.7s, tot_wait: 1.29s, rpc_num: 327, rpc_time: 1m55.6s, copr_cache_hit_ratio: 0.00, distsql_concurrency: 1} 636 Bytes N/A
└─Limit_10 cop[tikv] 1 offset:0, count:1 1 tikv_task:{proc max:690ms, min:1ms, avg: 345.3ms, p80:413ms, p95:450ms, iters:327, tasks:327}, scan_detail: {total_process_keys: 1, total_process_keys_size: 116, total_keys: 254783718, get_snapshot_time: 1.16s, rocksdb: {delete_skipped_count: 3025032, key_skipped_count: 257808423, block: {cache_hit_count: 4420, read_count: 383947, read_byte: 4.51 GB, read_time: 15.5s}}} N/A N/A
└─TableFullScan_9 cop[tikv] 1 table:t_label, keep order:false 1 tikv_task:{proc max:690ms, min:1ms, avg: 345.3ms, p80:413ms, p95:450ms, iters:327, tasks:327} N/A N/A
这是刚才的执行计划，执行时间还是很长(1 min 56.27 sec)
id task estRows operator info actRows execution info memory disk
Limit_7 root 1 offset:0, count:1 1 time:1m56.1s, loops:2 N/A N/A
└─TableReader_11 root 1 data:Limit_10 1 time:1m56.1s, loops:1, cop_task: {num: 330, max: 713.1ms, min: 1.4ms, avg: 351.8ms, p95: 462.6ms, max_proc_keys: 1, p95_proc_keys: 0, tot_proc: 1m52.7s, tot_wait: 1.45s, rpc_num: 330, rpc_time: 1m56.1s, copr_cache_hit_ratio: 0.00, distsql_concurrency: 1} 650 Bytes N/A
└─Limit_10 cop[tikv] 1 offset:0, count:1 1 tikv_task:{proc max:710ms, min:0s, avg: 341.9ms, p80:412ms, p95:448ms, iters:330, tasks:330}, scan_detail: {total_process_keys: 1, total_process_keys_size: 141, total_keys: 256948012, get_snapshot_time: 1.26s, rocksdb: {delete_skipped_count: 6519094, key_skipped_count: 263199928, block: {cache_hit_count: 4510, read_count: 390914, read_byte: 4.54 GB, read_time: 14.7s}}} N/A N/A
└─TableFullScan_9 cop[tikv] 1 table:t_label, keep order:false 1 tikv_task:{proc max:710ms, min:0s, avg: 341.9ms, p80:412ms, p95:448ms, iters:330, tasks:330}
你这个表是动态的吗？不会还在一直插入删除数据吧？
你用这个语句再看看：
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’
是在一直更新数据
说明自动compact有效果，就是很慢很慢了，如果可以停止表访问，还是重建表吧。
另外这表是在持续写入和删除或update吗？大概一天多少行（dml行数加起来）