WHERE IN 子句的优化策略

WHERE IN 子句的优化策略

WHERE IN 包含大量的元素的查询优化

应用端反馈一个涉及功能菜单渲染的基础SQL查询时间超过7秒,原因是where x in (上千个的元素),通过Presto观察,发现这个SQL的查询的时间90%花在了执行计划的解析上,真正查询时间反而很快。通过删减 where in 中的元素,发现SQL就快了很多,也证实了,问题的根本原因在in 元素集合过多

然后询问了下使用场景,是否可以减少元素,比如连续的元素改成 x < id < y 这种范围条件。答复是不行,是离散的,不是连续的,也无法减少元素

只能换一种sql 写法,当时第一时间想自定义一个RoaringBitMap(RBM)的contains 函数来测试,但是发现presto有一个数组的contains方法,因为RBM如果元素个数小于四千个内部也是数组,于是改写了sql,先试试 数组的contains()函数

where in 元素个数大概在2500个时,contains(Array[],element)的写法比 where x in (elements) 快了近10倍

后续加了rbmContains()函数,测试和 contains(Array[],element) 差不多,稍微快一点,rbmContains 优势应该体现在4K 以上的元素,rbm除了判断contains 还有其他很多用途,后续再补一篇RoaringBitmap 的文章

由于在拼SQL时,可以提前查询出元素数组个数,所以当元素个数小于50时,就用 where in ,大于50 小于4000 用 数组的contains,超过4000 就用rbmContains函数了


 

Comments

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×