还是要看看执行计划吧
楼主解决了没有?
其实大家都想看一下执行计划,limit 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完成,这些垃圾数据不再扫描到的时候,查询就会变快了。。。
感觉不是这样,连续的反复执行语句,也会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行数加起来)