可见版本数过多会导致查询变慢么？

Kongdom · 2023 年7 月 28 日 01:19

【 TiDB 使用环境】生产环境
【 TiDB 版本】v5.1.0
简单的一个聚合查询，可以命中索引，但是查询时间超过1分钟，检查GC设置的是24h。
可见副本过多会导致查询慢么？

select aa,sum(c_amount) from table 
where c_date > '2023-05-01' 
and c_date < '2023-07-01'  
group by aa
order by aa
limit 10

xfworld · 2023 年7 月 28 日 01:24

会，从一大串数据中去读取的时候，需要 skip，会减慢get 的速度

有需要的话，可以手动释放版本

Kongdom · 2023 年7 月 28 日 01:36

还发现一个问题，为什么hashagg了两次

xfworld · 2023 年7 月 28 日 01:42

一次 tikv，一次 tidb

每个tikv 节点 group by 拿到分组结果后，汇总到 tidb 在分组排序…

这样才能保证拿到正确的结果… （毕竟数据是分散在各个 tikv 上的，不能一次性完成分组汇总）

Kongdom · 2023 年7 月 28 日 01:53

那为什么IndexRangeScan一遍，又TableRowIDScan了一遍？

zhanggame1 · 2023 年7 月 28 日 01:55

当然会慢了，tidb的mvcc把历史数据和当前数据放一起了

redgame · 2023 年7 月 28 日 02:00

有影响的。

zhanggame1 · 2023 年7 月 28 日 02:01

TableRangeScan：带有范围的表数据扫描.
TableRowIDScan：根据上层传递下来的 RowID 扫描表数据。时常在索引读操作后检索符合条件的行。

具体来说就是通过c_date 列上的索引查到具体的rowid，然后，回表通过rowid查数据

1300万数据量加没有gc的数据快不了

裤衩儿飞上天 · 2023 年7 月 28 日 02:03

回表了

Kongdom · 2023 年7 月 28 日 02:11

强制用了一下TiFlash，1分钟变7秒，看来还是得强制用TiFlash啊

有猫万事足 · 2023 年7 月 28 日 02:20

第一次是group by 第二次是limit。hashagg之后立刻topn这就是limit。

Kongdom · 2023 年7 月 28 日 02:39

收到，已经决定用tiflash了

DBRE · 2023 年7 月 28 日 06:51

如何手动释放版本呢？

xfworld · 2023 年7 月 28 日 07:12

逻辑上数据被删除了，这个操作得有

然后通过手动控制 tikv 的 GC 来实现释放

DBRE · 2023 年7 月 28 日 07:14

get~

Kongdom · 2023 年7 月 28 日 07:40

cy6301567 · 2023 年7 月 28 日 10:26

date和aa有组合索引？

Kongdom · 2023 年7 月 29 日 01:19

没有，只有c_date有索引

cy6301567 · 2023 年7 月 31 日 02:44

尝试组合索引

Kongdom · 2023 年9 月 29 日 02:44

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