本文首发于泊浮目的掘金:juejin.cn/user/146860…
0. 前言
前阵子遇上了一个Starrocks上的SQL性能问题。之前没暴露原因有2:
- 没对单个SQL的内存消耗做限制。
- 不到黑五，量没有上来。
暴露以后，赶紧做了fix——本质上是一个left join的sql，因此先想当然的减少两边表的数据量，但效果并不尽人意。此时左表为小表，右表为大表。一个同事给了一个建议，试试大表join小表，结果性能一下子就上去了4倍。于是就有了今天这篇笔记。
1. Boardcast
一开始在Starrocks官网上搜没有找到什么有效的资料，包括其对执行计划的解读也不是很详细。想了想，只能“追溯其根源了”。便打开了DorisDB的官网，翻了翻，发现写得非常清晰。我简单总结下：
MPP库在Join时是需要Shuffle数据的，因为数据散落在各个节点中。那么其性能优化本质就是减少数据寻找、挪动的开销。最最常见的就是小表广播——当你的右表特别小的时候，这些数据会直接全量发到左表所在的数据节点（至内存），避免数据来回交换。
当然，你不想这么写SQL——即小表在左，大表在右也可以。开启set enable_cost_based_join_reorder = true即可，DorisDB会自动调整表的顺序。
2. 参考资料
- doris.apache.org/zh-CN/docs/…
