TiDB查询使用limit，会有优化效果吗，发现使用limit之后，还是扫描了非常多的key

🪐 TiDB 技术问题
1

【 TiDB 使用环境】生产环境 /测试/ Poc
【 TiDB 版本】v4.0.10
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
sql是有索引的，执行计划中也用到了索引
image

2

sql是limit 100

3

正常应该会下推的tikv 层过滤吧

4

是的，看执行计划应该在kv层就limit限制了，不知道为什么还会扫描这么多key

5

你说的优化是指哪方面？LIMIT本身有下推优化，但这个不是作为SQL优化的手段啊，即使加了LIMIT仍然可能扫描很多数据

6

和查询条件也有关系

7

发执行计划文本

8

执行计划发出来看看

9

整个sql和执行计划发出来，不然没法判断。
例如select a from t where b>10 limit 100如果b上没索引的话，不是只能全表扫到100行b>10的数据才行吗？那扫多少数据不是完全取决于你的数据是如何存放的？

10

查询条件有没有索引

11

执行计划，这行上面一行是TopN吗

12

升级吧，版本太低了…

旧的版本，支持的算子也比较有限了

13

如果加了order by xx limit 100，依然是会扫描很多行的。
主要是看你执行的sql语句

14

TiDB 使用 limit，在大部分情况下回下推到存储层进行过滤，以提高查询性能，但是有些场景为了保证结果准确性不会提前下推。

https://docs.pingcap.com/zh/tidb/stable/topn-limit-push-down#topn-和-limit-下推

楼主贴下你的具体SQL和执行计划，才可以进一步针对性分析。

15

需要看具体的执行计划欧

16

大家一起猜谜题 :joy:

17

查询条件没索引，加索引后不用 > 使用>=。如果索引排序了。查询时不要逆反的顺序尽心排序 查询。
虽好把查询语句， 表结构。表数据等信息说清楚，explain table结果发下。

18

CREATE TABLE xxxxxx (
id bigint(20) NOT NULL AUTO_INCREMENT COMMENT ‘id’,
uid bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
people_task_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
task_group_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
task_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
sub_task_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
sub_task_type int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
cycle_id int(11) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
progress_compute_end_time bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
next_compute_time bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
is_deleted tinyint(4) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
ctime datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT ‘xx’,
mtime datetime NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT ‘xx’,
gid bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
crowd_dimension tinyint(4) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
last_compute_time bigint(20) NOT NULL DEFAULT ‘0’ COMMENT ‘xx’,
PRIMARY KEY (id),
KEY idx_next_compute_time (next_compute_time),
KEY idx_progress_compute_end_time (progress_compute_end_time),
KEY idx_uid (uid),
KEY idx_people_task_id (people_task_id),
KEY idx_mtime (mtime),
UNIQUE KEY uk_uid_sub_task_id_cycle_id_gid (uid,sub_task_id,cycle_id,gid),
KEY idx_last_next_compute_time (last_compute_time,next_compute_time),
KEY idx_sub_task_type_last_next_compute_time (sub_task_type,last_compute_time,next_compute_time)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin AUTO_INCREMENT=14700001 COMMENT=‘xx’

19

SELECT id,uid,gid,crowd_dimension,people_task_id,task_group_id,task_id,sub_task_id,sub_task_type,cycle_id,progress_compute_end_time,next_compute_time,is_deleted,ctime,mtime,last_compute_time FROM anchor_task_center_progress_schedule_execute_info_0000 WHERE ((last_compute_time=0 AND next_compute_time>=1712825580) AND next_compute_time<=1716281580) AND sub_task_type IN (46,47,48,49,50,51,52,53,54,55,56,57,59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,76,77,78) LIMIT 100;

20

走的索引：idx_sub_task_type_last_next_compute_time