【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3.2
【问题现象及影响】
在某个复杂的sql中,通过每一步的执行时间确认了该sql时间的瓶颈就在某个left join的表每次全表扫1000万耗时高(没有过滤条件),但是在该表连接条件有索引。
并确认了另一个子连接的表也没有过滤条件(400万数据),也是一样,但是在执行计划中作为index join的 probe端走了索引
【做过的尝试】
![image](https://asktug.com/uploads/default/original/4X/5/9/d/59d0d6edf50c37e92ef997938832bf8717bac842.png)
【 TiDB 使用环境】生产环境
【 TiDB 版本】5.3.2
【问题现象及影响】
在某个复杂的sql中,通过每一步的执行时间确认了该sql时间的瓶颈就在某个left join的表每次全表扫1000万耗时高(没有过滤条件),但是在该表连接条件有索引。
并确认了另一个子连接的表也没有过滤条件(400万数据),也是一样,但是在执行计划中作为index join的 probe端走了索引
要开聚合索引
你指的是wti 这张表的两个链接条件创建联合索引?已经创建了
可以将hash join后的operator info 发出来下吗
left outer join, equal:[eq(k3_wms.wm_pick_distribute_item.to_item_id, k3_wms.wm_to_item.id) eq(Column#703, Column#704)]
看下to_id在两表中的类型,建议如果能把sql文本和执行计划文本发出来就好了
可以尝试调整下组合索引的顺序,顺序不同就可能生成不同的执行计划
实锤了有个连接条件的字段类型不一致,直接去掉了那个不匹配的连接条件,执行计划自己识别优化了这个地方
你说的这种情况我在其他地方见过
在mysql上优化过这类sql,索引顺序不同表的连接顺序也会不一样,本来是用hit测试的执行快了,然后改索引顺序直接会生成跟hit一样的执行计划
此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。