SQL 查询超过2分钟,执行计划显示limit慢

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】

SQL 查询超过2分钟,执行计划显示limit慢
SELECT * from table
WHERE I_ID in (
SELECT I_ID FROM table use index (IDX_SYNC_STATUS)
WHERE I_SYNC_STATUS = 0 limit 100
)

SQL 修改为
SELECT * from table
WHERE I_ID in (
SELECT I_ID FROM table use index (IDX_SYNC_STATUS)
WHERE I_SYNC_STATUS = 0
)
16s就执行完成了

【资源配置】
【附件:截图/日志/监控】

各位大佬,求赐教

不加limit快?另外统计信息该收集了

执行计划贴一下 看下慢 SQL 页面

数据量多大呢 ??

截图就是执行计划

总量20多亿,但是status=0的1000条

status distinct 后有几个值。 估计 没几个吧??

你这不是discount么 全表了

我想看下 直方图的统计信息。 估计要全表。

这个量,收集统计信息也不行吧。

改sql SELECT
floor((t.row_num - 1) / 1000) + 1 AS page_num,
min(t.id) AS start_key,
max(t.id) AS end_key,
count(*) AS page_size
FROM (
SELECT id, row_number() OVER (ORDER BY id) AS row_num
FROM books
) t
GROUP BY page_num
ORDER BY page_num;

出现stats:pseudo,直接analyze table 收集统计信息就可以了,绝对没错

不加limit


添加limit

不加limit16s,添加limit 3分钟

这个稳定复现吗? 感觉像是bug

多数时候会这样,偶尔正常

没看懂

确实没几个,但是我已经use index了

tikv_task:{proc max:450ms, min:59ms, p80:137ms, p95:189ms, iters:1848, tasks:1847}, scan_detail: {total_process_keys: 0, total_keys: 0, rocksdb: {delete_skipped_count: 0, key_skipped_count: 0, block: {cache_hit_count: 0, read_count: 0, read_byte: 0 Bytes}}}