有索引的列谓词越界+统计信息不及时,导致全表扫描

一个好的问题描述有利于社区小伙伴更快帮你定位到问题,高效解决你的问题

【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】7.1
【部署方式】云上部署(什么云)/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
索引的统计信息是20260513收集的,查询的谓词为当日,如下SQL就不进行索引扫描了,重新收集索引统计信息后才恢复正常。
这种有什么计算公式么? 或者向Oracle的10053的工具一样?
一旦表的数据量变动不大,不会经常收集统计信息,这类SQL的执行计划不就会经常不准确了?
mysql> explain analyze SELECT DISTINCT COLID FROM taba WHERE CREATE_TIME >= ‘2026-05-18’ ;
±-----------------------------±-----------±--------±----------±----------------------±------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------------------------------------------------------------------------------------------±---------±-----+
| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |
±-----------------------------±-----------±--------±----------±----------------------±------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------------------------------------------------------------------------------------------±---------±-----+
| HashAgg_12 | 1608.09 | 643 | root | | time:574.5ms, loops:6, RU:49638.078049, partial_worker:{wall_time:574.314032ms, concurrency:5, task_num:1, tot_wait:2.868088752s, tot_exec:568.095µs, tot_time:2.868739329s, max:574.218642ms, p95:574.218642ms}, final_worker:{wall_time:574.522225ms, concurrency:5, task_num:5, tot_wait:2.871281208s, tot_exec:820.77µs, tot_time:2.872106511s, max:574.49297ms, p95:574.49297ms} | group by:sk_pay.taba.COLID, funcs:firstrow(sk_pay.taba.COLID)->sk_pay.taba.COLID | 384.5 KB | N/A |
| └─TableReader_13 | 1608.09 | 998 | root | | time:573.6ms, loops:2, cop_task: {num: 123, max: 241.3ms, min: 611.1µs, avg: 54.7ms, p95: 155.6ms, max_proc_keys: 195007, p95_proc_keys: 127423, tot_proc: 6.61s, tot_wait: 45.5ms, rpc_num: 123, rpc_time: 6.73s, copr_cache_hit_ratio: 0.37, build_task_duration: 239.2µs, max_distsql_concurrency: 15} | data:HashAgg_5 | 9.46 KB | N/A |
| └─HashAgg_5 | 1608.09 | 998 | cop[tikv] | | tikv_task:{proc max:240ms, min:14ms, avg: 82.3ms, p80:106ms, p95:155ms, iters:8658, tasks:123}, scan_detail: {total_process_keys: 5921819, total_process_keys_size: 3106570721, total_keys: 5935096, get_snapshot_time: 41.9ms, rocksdb: {delete_skipped_count: 11670, key_skipped_count: 16963814, block: {cache_hit_count: 111824, read_count: 1415, read_byte: 43.8 MB, read_time: 21.1ms}}} | group by:sk_pay.taba.COLID, | N/A | N/A |
| └─Selection_11 | 231844.00 | 2497 | cop[tikv] | | tikv_task:{proc max:240ms, min:14ms, avg: 82.2ms, p80:106ms, p95:155ms, iters:8658, tasks:123} | ge(sk_pay.taba.create_time, 2026-05-18 00:00:00.000000) | N/A | N/A |
| └─TableFullScan_10 | 8803716.00 | 8803402 | cop[tikv] | table:taba | tikv_task:{proc max:233ms, min:14ms, avg: 79.3ms, p80:104ms, p95:151ms, iters:8658, tasks:123} | keep order:false | N/A | N/A |
±-----------------------------±-----------±--------±----------±----------------------±------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------±------------------------------------------------------------------------------------------------------------------------------------±---------±-----+
5 rows in set (0.57 sec)
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件:截图/日志/监控】

统计信息的问题是一个已知的问题,可以升级到 v8.5 的版本解决

看样子是不是遇到bug了

可以定时手工搜集一下,或者升级试试

tidb要想收集统计信息,那么变动的数据量/全量数据要达到一个比例,才会触发更新,默认是0.5

tidb_auto_analyze_ratio

如果你的表这个本来的数据量很大,那么触发统计信息的收集是很难的,所以你要看下,你这个表800万,那么要变化400万才会触发统计信息,所以你看下tidb_auto_analyze_ratio 这个值多大

看上去像是版本bug

可以搞个任务定时收集健康度低的表的统计信息

查询一下相关的健康度,看是否要analyze一下表

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。