StarRocks 性能调优实战（一）

一些用户在做 StarRocks的 POC 测试时，参照《 StarRocks企业版文档》进行了表模型选择、分区、分桶等基础配置后，查询性能离期望的理想状况可能还是会有些差异，或者想针对业务进一步优化以达到最佳性能。这里，我们就借用一个用户 POC 时的调优场景，来分享一些 StarRocks系统性能调优中的技巧，同时也简要介绍下 StarRocks企业版可视化 profiling 工具的使用。如果您使用的是 StarRocks标准版，可以通过文字版的 profiling 信息，用文中提及的一些方法优化。

下文将先介绍一些基础性的优化内容，包括如何优化 join、group by、索引等，再介绍针对不同方向上的一些优化，比如是提升单个 Query 的性能还是提升整体的 QPS 能力等。

遇到的问题

该用户在 POC 阶段优化性能时，总体遇到了下面 3 个问题，这些问题也是很多用户经常遇到的：

1. 如何优化单个 Query 的性能，以达到秒级甚至亚秒级的响应速度；
2. 如何提升系统整体 QPS 的能力，以让「一个大任务」（会拆分成很多小任务并行跑）的总时间尽可能短；
3. 如何通过适当增加机器数量，进一步提升系统性能。

基本的优化方法上，主要是减少不必要的资源开销、增加并行能力，再利用系统的一些能力，比如 join 方式、谓词下推等，进一步减少资源使用。在每类问题的极致优化方向上，会有些小的差异，需要根据不同需求使用不同的优化方式和一些参数。

说明一下，下文只单纯考虑如何优化 SQL。至于机器、网络、安全、导入、预聚型合物化视图等方面的优化或使用，不在本文介绍范围。

如何优化

MySQL、Oracle 等数据库系统，都提供了 explain 、show profile 等功能来帮助性能优化。 StarRocks也提供了这两个功能，它会展示一棵“以 Fragment 为节点，以 Exchange 为边的逻辑查询树”。每个 Fragment 节点可能包含 SCAN、JOIN、数据传输等具体操作，Fragment 在执行时分成多少个物理执行实例、具体做什么事、具体的数据读取/计算/hash 构建等步骤的消耗时间等。一般我们直接使用「执行时间」来可视化、结构化地查看 SQL 执行结构、计算资源消耗情况等。

在 StarRocks Manager 的 Web 页面中，点击「查询」页，点击需要的「查询 ID」，就可以看到如下图的功能项，选择并具体查看。

不同优化方向时，需要有区别地看待一些资源消耗的节点。同时，不同数据量、不同类型的 SQL，可能效果也会有些差异。在整体优化思想的指导下，多多实验，对比和思考差异的原因，以得到业务最优的 SQL 和配置。

基础优化

优化的主要思路：减少资源使用量。借助「执行时间」中的 profile 图，查看下图中的执行时间占比，优先优化占比高的处理节点。这里：

• 每个节点(算子)的进度条是执行时间占比。能直观地看到全局图中哪些节点耗 CPU 多、Scan 时间长；
• 行数是下面节点(算子)的总输出行数。对于性能有很直接的影响，往往“返回量大”代表着数据过滤效果不够、数据传输量大、后续处理更耗时。

此次 POC 场景有两个 SQL，后续简称 CASE-A 和 CASE-B。可以参见本文最后一张图，了解 CASE-A 的大致逻辑结构。其中每个 CASE 中的一些子逻辑会代称为「A 逻辑」、「B 逻辑」等。

一、优化基本的建表 SCHEMA 等

1. 选择合适的表模型、分区、分桶；（这块很重要，后续会有另一个教程来说明）

2. 没有特殊要求，尽量用 int 类型，减少字符串使用；

3. DATE 、DATETIME，不必要时尽量不要转换成字符串；

4. 特别是会作为 join condition 的列，更应该使用 int、DATE 等简单类型。

在 CASE-A 中，有一个 join 的 on condition 中，原本是“将 DATE 转化成字符串来比较”，而修改成“使用 date_trunc() 函数直接进行比较”后，性能得到明显提升：整个大 SQL 提升5~10%。

-- 修改前
DATE_FORMAT(DATE_N,'%Y-%m-%d') = DATE_FORMAT(DATE_S,