怎么不是batch_point_get呢

dbaspace · 2022 年2 月 21 日 13:14

tbl_shop_org orgid是主键，单个主键IN的时候实现point_get, in比较多的时候整个执行发送变化，执行效率非常慢，这里为什么不能是batch_point_get?

Lucien-卢西恩 · 2022 年2 月 21 日 14:36

需要看一下具体的 SQL 和 schema 信息,详情看一下官方文档.https://docs.pingcap.com/zh/tidb/v4.0/explain-indexes#point_get-和-batch_point_get

TiDB 直接从主键或唯一键检索数据时会使用 Point_Get 或 Batch_Point_Get 算子。这两个算子比 IndexLookup 更有效率。

dbaspace · 2022 年2 月 21 日 15:16

现在是tbl_shop_org orgid是主键，单独查询可以实现batch_point_get:

SELECT orgID FROM db_shop.aa WHERE groupID = 32sd and orgID in(…) 有500个值
这个SQL再一坨SQL里作为一个子查询处理，IN值多了就没法BATCH_POINT，IN一个值或几十个还能够batch_point_get，这个不是有什么值控制个数？

Kongdom · 2022 年2 月 22 日 00:34

可能分析器认为tablerangescan的效率和batchpointget的查询效率差不多。
表里一共多少条数据？

TiDBer_4oMELAVl · 2022 年2 月 22 日 01:00

IN后面数据量大了，使用TableRangeScan效率更高，对表的扫描次数降低了

dbaspace · 2022 年2 月 22 日 01:23

嗯……我看看……我把那一坨in的值单独查询走的是点差的……sql使用rang执行非常慢……

dbaspace · 2022 年2 月 22 日 01:24

in值不是连续的……这个range不见的好

TiDBer_NtDbUm7p · 2022 年2 月 22 日 02:02

走哪个路径是优化器来决定的，优化器是会计算成本，对比起来点差的成本高那就不会走这个路径

啦啦啦啦啦 · 2022 年2 月 22 日 02:03

mysql也一样，应该尽量避免in值过多的情况。

dbaspace · 2022 年2 月 22 日 02:05

mysql in 多有参数可以控制，能够解决它慢的问题，TIDB 不知道有没有办法

Orange_sword · 2022 年2 月 22 日 06:13

in 值过多，tidb也是cbo吧

TiDBer_L3dm6WTj · 2022 年2 月 22 日 12:25

大多数据库都是CBO

dbaspace · 2022 年2 月 22 日 15:34

340W

TiDBer_NtDbUm7p · 2022 年2 月 23 日 00:51

340W是指？

TiDBer_4oMELAVl · 2022 年2 月 23 日 01:32

340W应该是指数据量吧

dbaspace · 2022 年2 月 25 日 06:30

@啦啦啦啦啦 @Kongdom @Lucien-卢西恩 @Orange_sword @TiDBer_NtDbUm7p @TiDBer_L3dm6WTj
感谢各位，改写SQL逻辑就用上batch_piont_get

这道题我不会 · 2022 年2 月 25 日 06:40

方便告知下具体是如何改写 SQL 的吗？这样其他小伙伴遇到同类问题也可以借鉴下，谢谢。

dbaspace · 2022 年2 月 25 日 06:53

业务逻辑使用子查询，把子查询改成left join方式 ,左表条件是主键就出现需要batch_point_get算子，执行结果就非常快了

system · 2022 年10 月 31 日 19:25

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