尧图网站建设 
StarRocks 最佳实践全指南表设计分区 / 排序键 / 分桶、主键表与查询调优【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks本指南源自 StarRocks 官方文档 docs/en/best_practices/overview.md由资深数据库工程师撰写聚焦用效率换成本合理的表结构与查询调优不仅能显著提升查询速度更能通过降低存储、CPU 与对象存储如 S3API 开销来削减成本。读完本文你将掌握分区、排序键、分桶三大物理设计旋钮的选型方法论理解主键表三种索引形态的取舍与内存/存储代价并学会一套可落地的自顶向下查询调优流程。StarRocks 的性能并非只来自引擎本身更来自表布局与查询模式相匹配。本文围绕官方 Best Practices 的三大主线展开通用表设计分区、表聚类、分桶、主键表实时更新场景下的索引与资源权衡、查询调优从定位问题到验证迭代的完整闭环并结合仓库源码中的真实配置项佐证每个结论。通用表设计三个物理设计旋钮官方文档将通用表设计归纳为三份指南分区、表聚类排序键、分桶。三者解决的是不同维度的问题分区负责粗粒度裁剪与生命周期管理排序键负责数据物理顺序带来的 I/O 消除分桶负责并行度与数据分布。分区Partitioning让查询少扫数据快速分析始于与查询模式匹配的表布局。分区帮助实现四个目标通过激进的裁剪少扫数据、以元数据级操作管理生命周期TTL、GDPR 删除、分层存储、随租户数/数据量/保留窗口平滑扩展、以及控制写放大新数据落入热分区压缩发生在历史分区。分区与分桶分工不同维度分区Partitioning分桶Hash/Random Bucketing核心目标粗粒度数据裁剪与生命周期控制TTL、归档分区内部的细粒度并行与数据局部性规划器可见性分区是 Catalog 对象FE 可基于谓词跳过仅等值谓词支持桶裁剪生命周期操作DROP PARTITION仅元数据操作适合 GDPR 删除、月度滚动桶不可单独删除只能通过ALTER TABLE ... MODIFY DISTRIBUTED BY变更典型数量每表 10²–10⁴ 个按天、周、租户每分区 10–120 个由BUCKETS xxx控制倾斜处理合并/拆分分区考虑复合/混合方案提高桶数、复合键哈希、隔离鲸鱼租户或使用随机分桶危险信号超过 10 万个分区会给 FE 带来显著内存占用每 BE 超过 20 万个 Tablet、单 Tablet 超 10 GB 可能引发压缩问题何时需要分区表类型是否分区典型键事实表 / 事件流是date_trunc(day, event_time)超大维表数十亿行视情况时间或业务键变更日期小型维表 / 查找表否依赖哈希分布如何选择分区键时间优先默认若 80% 的查询带时间过滤优先使用date_trunc(day, dt)。租户隔离需要按租户管理数据时将tenant_id加入分区键。保留对齐把计划清理的列放入分区键。复合键注意分区爆炸PARTITION BY tenant_id, date_trunc(day, dt)裁剪完美但会产生租户数 × 天数个分区总量需控制在约 10 万以内否则 FE 内存与 BE 压缩都会受影响。粒度选择PARTITION BY date_trunc(day, dt)的粒度可按场景调整为 hour、day、month 等函数详情见 date_trunc。粒度适用场景优点缺点日默认大多数 BI 与报表分区少每年 365 个、TTL 简单对最近 3 小时类查询精度不足小时每天写入量超 2× Tablet 数、IoT 突发热点隔离每天 24 个分区每年约 8700 个分区周 / 月历史归档元数据极小、易于合并裁剪较粗经验法则每个分区控制在 ≤100 GB跨副本的每分区 Tablet 数 ≤2 万。自 3.4 版本起StarRocks 还支持通过将历史分区合并为更粗粒度实现混合粒度分区。实战模板单租户点击流事实表CREATE TABLE click_stream ( user_id BIGINT, event_time DATETIME, url STRING, ... ) DUPLICATE KEY(user_id, event_time) PARTITION BY date_trunc(day, event_time) DISTRIBUTED BY HASH(user_id) BUCKETS xxx;多租户 SaaS 指标推荐模式 A按时间裁剪、同租户数据共置CREATE TABLE metrics ( tenant_id INT, dt DATETIME, metric_name STRING, v DOUBLE ) PRIMARY KEY(tenant_id, dt, metric_name) PARTITION BY date_trunc(DAY, dt) DISTRIBUTED BY HASH(tenant_id) BUCKETS xxx;鲸鱼租户复合模式模式 B需警惕分区爆炸CREATE TABLE activity ( tenant_id INT, dt DATETIME, id BIGINT, .... ) DUPLICATE KEY(dt, id) PARTITION BY tenant_id, date_trunc(MONTH, dt) DISTRIBUTED BY HASH(id) BUCKETS xxx;表聚类Table Clustering排序键是杠杆最高的物理设计旋钮一个深思熟虑的排序键Sort Key是 StarRocks 中杠杆率最高的物理设计参数。以遥测系统为例每天数十亿行、每行带device_id与ts定义ORDER BY (device_id, ts)可带来——按device_id的点查毫秒级返回、按设备过滤近期时间窗口的仪表盘查询大量裁剪、GROUP BY device_id的流式聚合、以及按设备相近时间戳的连续序列带来的更高压缩比。CREATE TABLE telemetry ( device_id VARCHAR, ts DATETIME, value DOUBLE ) ENGINEOLAP PRIMARY KEY(device_id, ts) PARTITION BY date_trunc(day, ts) DISTRIBUTED BY HASH(device_id) BUCKETS 16 ORDER BY (device_id, ts);排序键的四大收益1. 海量 I/O 消除——Segment 与 Page 裁剪。每个 Segment 和 64 KB Page 都存储所有列的 min/max 值谓词落在范围之外时 StarRocks 直接跳过整块数据、绝不触碰磁盘。例如ORDER BY (tenant_id, ts)下查询WHERE tenant_id 42 AND ts BETWEEN 2025-05-01 AND 2025-05-07时只有首键为 42 的 Segment 被纳入考虑其中也仅 ts 窗口与这七天重叠的 Page 被扫描——1000 亿行的表可能只需扫描不到 10 亿行把分钟级查询变成秒级。2. 毫秒级点查——稀疏前缀索引。前缀索引每约 1000 行存储一个排序键值二分查找定位到正确 Page 后一次磁盘读通常已命中缓存即返回行。对ORDER BY (order_id)的表执行WHERE order_id 982347234在 500 亿行规模下也只需约 50 次键比较冷缓存下延迟低于 10 ms。3. 更快的排序聚合。当排序键与GROUP BY对齐时StarRocks 在扫描过程中直接做流式聚合无需排序或哈希表。对ORDER BY (device_id, ts)的表执行GROUP BY device_id引擎边流入边分组充分利用 CPU 缓存局部性、跳过中间物化。对高基数列流式聚合的吞吐通常比哈希聚合提升 2–3 倍。4. 更高压缩比与更热缓存。有序数据呈现小增量或长游程加速字典、RLE、frame-of-reference 编码紧凑的 Page 顺序流过 CPU 缓存。文档给出的实测案例按(device_id, ts)排序的遥测表比未排序摄入的同一数据 LZ4 压缩比提升 1.8 倍、CPU/扫描开销降低 25%。排序键如何工作从写入到读取的生命周期写路径行落入 MemTable 后按声明的排序键排序刷新为新 Rowset含一个或多个有序 Segment后台 cumulative/base 压缩任务把小 Rowset 合并为大 Rowset、回收删除并降低 Segment 数因所有源 Rowset 共享同一顺序而无需重新排序每个 Tablet 同步复制到对端 BE保证副本间顺序一致。存储层级分区粗粒度逻辑切片启用规划期裁剪并隔离 TTL/批量加载生命周期操作→ Tablet分区内按哈希/随机分桶、跨 BE 独立复制行按排序键物理有序→ MemTable约 96 MB 内存写缓冲落盘前按声明键排序保证每个磁盘 Segment 天然有序→ Rowset一次 flush、流式加载或压缩周期产生的不可变 Segment 束追加式设计支持并发摄入与无锁读→ Segment约 512 MB 自包含列式文件携带数据页与裁剪索引。Segment 文件内部自顶向下64 KB 列数据页Dictionary/RLE/Delta 编码默认 LZ4 压缩→ Ordinal 索引行序 → 页偏移→ Zone-map 索引每页与整个 Segment 的 min/max/has_null裁剪第一道防线→ Short-key前缀索引每约 1000 行一个、基于排序键前 36 字节的稀疏二分表支持毫秒级点查/范围查找→ Footer 与魔数各索引偏移与完整性校验StarRocks 仅内存映射尾部即可发现其余结构。读路径规划期分区裁剪dt BETWEEN谓词只打开匹配分区目录→ 规划期 Tablet 裁剪等值过滤含哈希分布列时计算目标 Tablet ID→ 前缀索引查找前导排序列定位精确 Segment/Page→ Zone-map 裁剪按 min/max 丢弃不命中谓词窗口的块→ 向量化扫描与延迟物化存活的列页顺序流过 CPU 缓存仅物化被引用的行与列。由于每次 flush 都以键序提交数据各裁剪层层层叠加最终实现数十亿行表上的亚秒级扫描。如何选择有效的排序键从工作负载洞察出发分析 Top-N 查询模式——等值谓词/IN列是理想的前导候选范围谓词时间戳、数值范围通常跟在等值列之后若范围列也出现在GROUP BY中将其前移可启用排序聚合高频 join/分组键也应考虑前置。同时度量基数高基数列数百万去重值裁剪效果最好。启发式规则顺序为高选择性等值列→主范围列→聚类辅助列低基数列放在高基数列之前可增强压缩宽度保持在 3–5 列过宽会拖慢摄入并撑爆 36 字节前缀索引限制过长的前导字符串列可能占满 36 字节前缀索引额度导致后续排序列无法被有效索引削弱前缀索引裁剪力、降低点查性能。与其他设计旋钮协同分区键应比前导排序列更粗例如PARTITION BY dateORDER BY (tenant_id, ts)让分区裁剪先移除整段日期范围、排序裁剪再处理内部分桶与排序使用相同列目的不同分桶保证集群内均匀分布排序实现 I/O 消除主键表默认以主键为排序键但也可附加列优化物理顺序聚合表与明细表遵循上述分析谓词驱动的排序键策略。参考模板场景分区排序键理由B2C 订单date_trunc(day, order_ts)(user_id, order_ts)多数查询先按用户、再按近期时间范围过滤IoT 遥测date_trunc(day, ts)(device_id, ts)设备维度时序读取占主导SaaS 多租户tenant_id(dt, event_id)分区实现租户隔离按天聚簇服务仪表盘维度查找无(dim_id)小表纯点查单列足矣分桶Bucketing哈希分桶还是随机分桶分桶是一份选择哈希分桶与随机分桶的速查指南。先看快速对比维度哈希分桶随机分桶示例DISTRIBUTED BY HASH(id) BUCKETS 16DISTRIBUTED BY RANDOM键声明必须HASH(col1, …)无——行按 round-robin 分配省略时的初始桶数创建时自动选择之后固定创建时自动选择设置 bucket_size 后可增长Tablet 拆分/收缩手动ALTER … BUCKETS自动拆分仅增长v3.2倾斜抵抗力取决于键基数高——设计上均匀桶裁剪✅过滤、join全 Tablet 扫描Colocate join✅本地聚合 / bucket-shuffle join✅支持的表类型全部仅明细Duplicate Key表哈希分桶行按一个或多个列的哈希值分配到 Tablet创建后 Tablet 数固定除非手动 ALTER。要求必须预先选择稳定、均匀、高基数的键——键基数通常应为 BE 节点数的 1000 倍以上以防范桶间数据倾斜初始桶大小应合理理想为 1–10 GB。优势查询局部性选择性过滤与 join 触碰更少 Tabletcolocate join事实表/维表共享哈希键实现高速 join可预测布局同键行始终落在一起本地聚合与 bucket-shuffle join跨分区哈希布局一致减少大 join 的 shuffle 开销。劣势数据分布倾斜时易出现热 TabletTablet 数静态扩容需维护 DDLTablet 不足会损害摄入、压缩与查询并行度Tablet 过多会膨胀元数据。实战示例维表-事实表 join 与 Tablet 裁剪-- 事实表按 (customer_id) 哈希分桶 CREATE TABLE sales ( sale_id bigint, customer_id int, sale_date date, amount decimal(10,2) ) ENGINE OLAP DISTRIBUTED BY HASH(customer_id) BUCKETS 48 PARTITION BY date_trunc(DAY, sale_date) PROPERTIES (colocate_with group1); -- 维表以相同键与桶数与 sales 表 colocate CREATE TABLE customers ( customer_id int, region varchar(32), status tinyint ) ENGINE OLAP DISTRIBUTED BY HASH(customer_id) BUCKETS 48 PROPERTIES (colocate_with group1); -- Tablet 裁剪仅访问单个 Tablet SELECT sum(amount) FROM sales WHERE customer_id 123; -- 本地聚合跳过 shuffle 聚合阶段 SELECT customer_id, sum(amount) AS total_amount FROM sales GROUP BY customer_id ORDER BY total_amount DESC LIMIT 100; -- Colocate join各 BE 本地配对 join无需网络 shuffle SELECT c.region, sum(s.amount) FROM sales s JOIN customers c USING (customer_id) WHERE s.sale_date BETWEEN 2025-01-01 AND 2025-01-31 GROUP BY c.region;何时使用哈希分桶模式稳定、分布过滤/join 键明确受益于桶裁剪的数仓负载需要 colocate join / bucket shuffle join / 本地聚合等特定优化使用聚合表或主键表。随机分桶行按 round-robin 分配、无需指定键设置PROPERTIES (bucket_sizebytes)后v3.2StarRocks 会随分区增长自动拆分 Tablet。优势零设计债无键、无桶计算写入抗倾斜磁盘与 BE 间压力均匀弹性增长Tablet 拆分保持摄入速度。劣势无桶裁剪每个查询扫描分区内全部 Tablet无 colocate join无键布局阻碍局部性目前仅支持明细表。何时使用日志/事件表或键会变化/倾斜的多租户 SaaS 表写入密集、均匀摄入吞吐至关重要的管道。运维指南随机分桶建议设置桶大小如 1 GiB以启用自动拆分哈希分桶需监控 Tablet 大小在 Tablet 超过 5–10 GiB 前重新分片。主键表Primary Key Tables实时更新的代价与取舍主键表使用 StarRocks 自研的新存储引擎核心优势是支持实时数据更新同时保持复杂 ad-hoc 查询的高效性能。实时业务分析中决策者可以基于最新数据实时分析缓解数据分析中的延迟问题。但主键并非免费的午餐——使用不当会造成不必要的资源浪费。选择主键索引类型主键索引Primary Index是主键表最关键的组件存储主键值与数据行位置之间的映射。目前支持三种类型全内存主键索引不推荐会造成显著内存浪费PROPERTIES ( enable_persistent_index false );本地磁盘持久化主键索引PROPERTIES ( enable_persistent_index true, persistent_index_type LOCAL );云原生持久化主键索引shared-data 弹性集群推荐PROPERTIES ( enable_persistent_index true, persistent_index_type CLOUD_NATIVE );官方明确不建议使用内存索引。若使用 shared-data弹性集群推荐云原生持久化主键索引与本地磁盘持久化索引不同它将完整索引数据存放于远端对象存储本地磁盘仅作缓存。相比本地磁盘持久化索引其优势是不依赖本地磁盘容量数据分片再平衡后无需重建索引。选择主键主键通常不帮助加速查询——可通过ORDER BY指定不同于主键的列作为排序键来加速查询。因此选主键时只需考虑导入与更新过程中的唯一性。主键越大消耗的内存、I/O 等资源越多因此一般建议避免选择过多或过大的列作为主键。主键默认最大 128 字节由be.conf中的primary_key_limit_size控制对应源码 be/src/common/config.h 中CONF_mInt32(primary_key_limit_size, 128)的默认值。可增大该值以支持更大的主键但需注意资源消耗上升。持久化索引空间占用估算存储空间(key size 8 bytes) * row count * 50%50% 为估计压缩效率实际取决于数据本身内存空间min(l0_max_mem_usage * tablet cnt, update_memory_limit_percent * BE process memory)。内存使用监控与调优主键表内存可通过 mem_tracker 监控// 查看整体内存统计 http://be_ip:be_http_port/mem_tracker // 查看主键表内存统计 http://be_ip:be_http_port/mem_tracker?typeupdate // 查看更详细的主键表内存统计 http://be_ip:be_http_port/mem_tracker?typeupdateupper_level4mem_tracker中的update项记录主键表使用的全部内存主键索引、delete vector 等也可通过指标监控服务如 Grafana观察。若对内存敏感、希望降低主键表导入过程的内存消耗可调整以下配置均在be.confl0_max_mem_usage (小于 104857600 的值默认 104857600) // Shared-nothing 集群 transaction_apply_worker_count (小于 CPU 核数的值默认为 CPU 核数) // Shared-data 集群 transaction_publish_version_worker_count (小于 CPU 核数的值默认为 CPU 核数)l0_max_mem_usage控制每个 Tablet 持久化主键索引的最大内存使用源码 config.h 默认 104857600 字节transaction_apply_worker_count与transaction_publish_version_worker_count均控制处理主键表 upsert/delete 的最大线程数。但需谨记降低l0_max_mem_usage可能增加 I/O 压力减少 worker 数可能拖慢数据摄入。压缩资源、数据新鲜度与查询延迟的三角权衡相比其他模型主键表在导入、更新、删除时需要额外的主键索引查找与 delete vector 生成操作引入额外资源开销因此需在以下三者间权衡压缩资源限制、数据新鲜度、查询延迟。数据新鲜度 查询延迟若既要更好新鲜度又要更好查询延迟意味着高频写入且需尽快压缩需要更多压缩资源// shared-data be.conf compact_threads 4 // shared-nothing be.conf update_compaction_num_threads_per_disk 1 update_compaction_per_tablet_min_interval_seconds 120可增大compact_threads、update_compaction_num_threads_per_disk或减小update_compaction_per_tablet_min_interval_seconds源码默认值见 config.h、config.h来投入更多压缩资源。如何判断压缩跟不上高频写入Shared-data 集群压缩跟不上会导致摄入变慢甚至写入失败。摄入变慢可通过show proc /transactions/{db_name}/running检查若 ErrMsg 出现Partitions compaction score is larger than 100.0, delay commit for xxxms. You can try to increase compaction concurrency说明发生摄入变慢若出现Failed to load data into partition xxx, because of too large compaction score...说明摄入已停止。Shared-nothing 集群无摄入变慢策略压缩跟不上会直接报错Failed to load data into tablet xxx, because of too many versions...。数据新鲜度 压缩资源受限压缩资源有限但需维持足够新鲜度就要牺牲部分查询延迟Shared-data 集群fe.conf调大lake_ingest_slowdown_threshold默认 100触发摄入变慢的压缩分数阈值与lake_compaction_score_upper_bound默认 2000触发摄入停止的阈值Shared-nothing 集群be.conf调大tablet_max_versions默认 1000源码见 config.h触发摄入停止的版本数阈值。增大这些配置可容纳更多小数据文件、降低压缩频率但会影响查询延迟。查询延迟 压缩资源受限想用有限压缩资源获得好查询延迟需要降低写入频率、以更大批次摄入数据具体做法参见各摄入方式章节降低摄入频率、增大批大小。查询调优Query Tuning自顶向下的五步闭环查询调优 是 StarRocks 实现高性能与高可靠性的关键。该目录汇集实用指南、参考资料与可落地的配方覆盖从编写 SQL 到解读执行细节的每个阶段。有效的查询调优遵循自顶向下流程识别问题检测慢查询、高资源占用或异常结果借助内置监控、查询历史与审计日志快速定位问题查询。参见 Query Tuning Recipes症状驱动诊断与 Query Profile Overview查询历史与 Profile。收集并分析执行信息用EXPLAIN或EXPLAIN ANALYZE获取查询计划开启并研读 Query Profile 获取详细执行指标。参见 Query Plan Overview、Explain Analyze Text-Based Profile Analysis 与 Query Profile Overview。定位根因找出耗时/耗资源最高的 Stage 或 Operator排查常见问题join 顺序欠佳、索引缺失、数据分布问题、低效 SQL 模式。参见 Query Profile Metrics 与 Query Tuning Recipes。应用调优策略SQL 改写加过滤、避免SELECT *Schema 调优加索引、换表型、调分区/聚类查询计划调优必要时用 hint 或变量引导优化器执行调优针对负载调会话变量。参见 Schema Tuning Recipes、Query Hint 与 Query Tuning Recipes。验证并迭代重跑查询、对比改动前后性能复查新计划与 Profile必要时重复。无论你是 DBA、开发还是数据工程师这套资源都能帮助你诊断并解决慢查询或资源密集型查询理解优化器选择与执行细节应用最佳实践与高级调优策略。Query Profile开启与获取Query Profile 记录查询涉及的所有工作节点的执行信息是诊断与调优的利器。开启方式SET enable_profile true; -- 会话级 SET GLOBAL enable_profile true; -- 全局级生产环境不建议长时间全局开启有额外开销可设置big_query_profile_threshold只捕获慢查询对应 FE 源码 SessionVariable.java 中的BIG_QUERY_PROFILE_THRESHOLD变量SET global big_query_profile_threshold 30s; -- 仅超 30 秒的查询 SET global big_query_profile_threshold 500ms; -- 仅超 500 毫秒 SET global big_query_profile_threshold 60m; -- 仅超 60 分钟长查询可用 Runtime Query Profilev3.1在执行期间按固定间隔上报默认间隔 10 秒可用SET runtime_profile_report_interval 30;调整。关键配置一览配置项类型合法值默认说明enable_profile会话变量true/falsefalse开启 Query Profilepipeline_profile_level会话变量1/211 合并指标2 保留原始结构禁用可视化工具runtime_profile_report_interval会话变量正整数10Runtime Query Profile 上报间隔秒big_query_profile_threshold会话变量字符串0s超过该时长的查询开启 Profile如 30s、500ms、60menable_statistics_collect_profileFE 动态true/falsefalse为统计信息收集相关查询开启 Profile获取方式Web UI 访问http://fe_ip:fe_http_port→ 顶部导航点击queries→ 在Finished Queries列表选择目标查询并点击Profile列链接或通过 SQL 函数get_query_profile配合last_query_id()获取最近查询 ID、show profilelist;列出近期查询与状态。自 v3.3.0 起INSERT INTO FILES()与 Broker Load 也支持 Query Profile。症状到修复按 Operator 的调优配方Query Tuning Recipes 提供症状 → 根因 → 已验证修复的实用手册。快速诊断流程先浏览执行概览QueryPeakMemoryUsagePerNode 80%或QuerySpillBytes 1 GB直接进入内存/溢写配方再在 Profile UI 按OperatorTotalTime %排序定位最热 Operator最后匹配各配方的特征指标模式再实施修复。以 Scan扫描Operator 为例存储引擎依次使用数据存储段内压缩编码数据多种索引、索引过滤Bitmap、Bloomfilter、Zonemap、ShortKey、NGram 索引跳过无关数据、谓词下推a 1类简单谓词推到列级求值、延迟物化仅从磁盘取所需列与过滤后的行、非下推谓词求值、投影表达式计算。常见瓶颈与对策包括冷/慢存储BytesRead/ScanTime/IOTaskExecTime占主导时换 NVMe/SSD 并启用 Data Cache按 BEdatacache_*与会话变量enable_scan_datacache配置过滤下推缺失PushdownPredicates接近 0 而ExprFilterRows高时改写为简单比较、避免%LIKE%与宽OR链或加 zonemap/Bloom 索引/物化视图线程池饥饿高IOTaskWaitTime伴低PeakIOTasks时扩容 Data Cache 与热存储Tablet 数据倾斜最大与最小OperatorTotalTime差距大时改用高基数列或增桶数Rowset/Segment 碎片化RowsetsReadCount/SegmentsReadCount暴涨时手动压缩并批量加载软删除累积DeleteFilterRows大时运行 BE 压缩清除。聚合AggregateOperator 方面StarRocks 依据查询模式与优化器决策采用多形态算法哈希聚合键可入内存、基数不极端SIMD 探测的紧凑哈希表、排序聚合输入已按 GROUP BY 键有序零哈希表成本高偏斜探测下常快 2–3 倍、可溢写聚合3.2哈希表超出内存限制时混合哈希/合并磁盘溢写分区防 OOM 且保持管道并行。分布式聚合为多阶段一阶段DISTRIBUTED BY是GROUP BY子集且分区共置局部聚合即最终结果、两阶段 localglobal典型分布式GROUP BY、三阶段 localshufflefinal重度DISTINCT与高基数GROUP BY、四阶段重度DISTINCT与低基数GROUP BY时增加阶段避免单点瓶颈。总结StarRocks 的高性能源于物理设计匹配查询模式这一原则的层层落实分区用粗粒度裁剪与元数据级生命周期操作换来 I/O 与运维成本的下降排序键通过在写路径上建立顺序、在 Segment 内构建微型索引让读路径上的每层裁剪互相叠加实现数十亿行表上的亚秒级扫描分桶在分区内部决定并行度与数据局部性哈希分桶换取裁剪/colocate/本地聚合能力随机分桶换取抗倾斜与弹性增长。主键表则以可控的索引内存与压缩资源为代价换来实时更新与复杂 ad-hoc 查询兼得的能力其三种索引形态与primary_key_limit_size、l0_max_mem_usage、tablet_max_versions等配置均可对照 be/src/common/config.h 中的真实默认值提供了精细的资源调节空间。最后查询调优用EXPLAIN/Query Profile 等工具支撑的五步闭环将上述设计决策与运行时行为连接起来形成设计-观测-调优-验证的完整方法论。继续深入可参阅分区、表聚类、分桶、主键表、查询调优概览、Query Profile 概览 与 Query Tuning Recipes。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 StarRocks 最佳实践全指南：表设计（分区 / 排序键 / 分桶）、主键表与查询调优
StarRocks 最佳实践全指南表设计分区 / 排序键 / 分桶、主键表与查询调优【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks本指南源自 StarRocks 官方文档 docs/en/best_practices/overview.md由资深数据库工程师撰写聚焦用效率换成本合理的表结构与查询调优不仅能显著提升查询速度更能通过降低存储、CPU 与对象存储如 S3API 开销来削减成本。读完本文你将掌握分区、排序键、分桶三大物理设计旋钮的选型方法论理解主键表三种索引形态的取舍与内存/存储代价并学会一套可落地的自顶向下查询调优流程。StarRocks 的性能并非只来自引擎本身更来自表布局与查询模式相匹配。本文围绕官方 Best Practices 的三大主线展开通用表设计分区、表聚类、分桶、主键表实时更新场景下的索引与资源权衡、查询调优从定位问题到验证迭代的完整闭环并结合仓库源码中的真实配置项佐证每个结论。通用表设计三个物理设计旋钮官方文档将通用表设计归纳为三份指南分区、表聚类排序键、分桶。三者解决的是不同维度的问题分区负责粗粒度裁剪与生命周期管理排序键负责数据物理顺序带来的 I/O 消除分桶负责并行度与数据分布。分区Partitioning让查询少扫数据快速分析始于与查询模式匹配的表布局。分区帮助实现四个目标通过激进的裁剪少扫数据、以元数据级操作管理生命周期TTL、GDPR 删除、分层存储、随租户数/数据量/保留窗口平滑扩展、以及控制写放大新数据落入热分区压缩发生在历史分区。分区与分桶分工不同维度分区Partitioning分桶Hash/Random Bucketing核心目标粗粒度数据裁剪与生命周期控制TTL、归档分区内部的细粒度并行与数据局部性规划器可见性分区是 Catalog 对象FE 可基于谓词跳过仅等值谓词支持桶裁剪生命周期操作DROP PARTITION仅元数据操作适合 GDPR 删除、月度滚动桶不可单独删除只能通过ALTER TABLE ... MODIFY DISTRIBUTED BY变更典型数量每表 10²–10⁴ 个按天、周、租户每分区 10–120 个由BUCKETS xxx控制倾斜处理合并/拆分分区考虑复合/混合方案提高桶数、复合键哈希、隔离鲸鱼租户或使用随机分桶危险信号超过 10 万个分区会给 FE 带来显著内存占用每 BE 超过 20 万个 Tablet、单 Tablet 超 10 GB 可能引发压缩问题何时需要分区表类型是否分区典型键事实表 / 事件流是date_trunc(day, event_time)超大维表数十亿行视情况时间或业务键变更日期小型维表 / 查找表否依赖哈希分布如何选择分区键时间优先默认若 80% 的查询带时间过滤优先使用date_trunc(day, dt)。租户隔离需要按租户管理数据时将tenant_id加入分区键。保留对齐把计划清理的列放入分区键。复合键注意分区爆炸PARTITION BY tenant_id, date_trunc(day, dt)裁剪完美但会产生租户数 × 天数个分区总量需控制在约 10 万以内否则 FE 内存与 BE 压缩都会受影响。粒度选择PARTITION BY date_trunc(day, dt)的粒度可按场景调整为 hour、day、month 等函数详情见 date_trunc。粒度适用场景优点缺点日默认大多数 BI 与报表分区少每年 365 个、TTL 简单对最近 3 小时类查询精度不足小时每天写入量超 2× Tablet 数、IoT 突发热点隔离每天 24 个分区每年约 8700 个分区周 / 月历史归档元数据极小、易于合并裁剪较粗经验法则每个分区控制在 ≤100 GB跨副本的每分区 Tablet 数 ≤2 万。自 3.4 版本起StarRocks 还支持通过将历史分区合并为更粗粒度实现混合粒度分区。实战模板单租户点击流事实表CREATE TABLE click_stream ( user_id BIGINT, event_time DATETIME, url STRING, ... ) DUPLICATE KEY(user_id, event_time) PARTITION BY date_trunc(day, event_time) DISTRIBUTED BY HASH(user_id) BUCKETS xxx;多租户 SaaS 指标推荐模式 A按时间裁剪、同租户数据共置CREATE TABLE metrics ( tenant_id INT, dt DATETIME, metric_name STRING, v DOUBLE ) PRIMARY KEY(tenant_id, dt, metric_name) PARTITION BY date_trunc(DAY, dt) DISTRIBUTED BY HASH(tenant_id) BUCKETS xxx;鲸鱼租户复合模式模式 B需警惕分区爆炸CREATE TABLE activity ( tenant_id INT, dt DATETIME, id BIGINT, .... ) DUPLICATE KEY(dt, id) PARTITION BY tenant_id, date_trunc(MONTH, dt) DISTRIBUTED BY HASH(id) BUCKETS xxx;表聚类Table Clustering排序键是杠杆最高的物理设计旋钮一个深思熟虑的排序键Sort Key是 StarRocks 中杠杆率最高的物理设计参数。以遥测系统为例每天数十亿行、每行带device_id与ts定义ORDER BY (device_id, ts)可带来——按device_id的点查毫秒级返回、按设备过滤近期时间窗口的仪表盘查询大量裁剪、GROUP BY device_id的流式聚合、以及按设备相近时间戳的连续序列带来的更高压缩比。CREATE TABLE telemetry ( device_id VARCHAR, ts DATETIME, value DOUBLE ) ENGINEOLAP PRIMARY KEY(device_id, ts) PARTITION BY date_trunc(day, ts) DISTRIBUTED BY HASH(device_id) BUCKETS 16 ORDER BY (device_id, ts);排序键的四大收益1. 海量 I/O 消除——Segment 与 Page 裁剪。每个 Segment 和 64 KB Page 都存储所有列的 min/max 值谓词落在范围之外时 StarRocks 直接跳过整块数据、绝不触碰磁盘。例如ORDER BY (tenant_id, ts)下查询WHERE tenant_id 42 AND ts BETWEEN 2025-05-01 AND 2025-05-07时只有首键为 42 的 Segment 被纳入考虑其中也仅 ts 窗口与这七天重叠的 Page 被扫描——1000 亿行的表可能只需扫描不到 10 亿行把分钟级查询变成秒级。2. 毫秒级点查——稀疏前缀索引。前缀索引每约 1000 行存储一个排序键值二分查找定位到正确 Page 后一次磁盘读通常已命中缓存即返回行。对ORDER BY (order_id)的表执行WHERE order_id 982347234在 500 亿行规模下也只需约 50 次键比较冷缓存下延迟低于 10 ms。3. 更快的排序聚合。当排序键与GROUP BY对齐时StarRocks 在扫描过程中直接做流式聚合无需排序或哈希表。对ORDER BY (device_id, ts)的表执行GROUP BY device_id引擎边流入边分组充分利用 CPU 缓存局部性、跳过中间物化。对高基数列流式聚合的吞吐通常比哈希聚合提升 2–3 倍。4. 更高压缩比与更热缓存。有序数据呈现小增量或长游程加速字典、RLE、frame-of-reference 编码紧凑的 Page 顺序流过 CPU 缓存。文档给出的实测案例按(device_id, ts)排序的遥测表比未排序摄入的同一数据 LZ4 压缩比提升 1.8 倍、CPU/扫描开销降低 25%。排序键如何工作从写入到读取的生命周期写路径行落入 MemTable 后按声明的排序键排序刷新为新 Rowset含一个或多个有序 Segment后台 cumulative/base 压缩任务把小 Rowset 合并为大 Rowset、回收删除并降低 Segment 数因所有源 Rowset 共享同一顺序而无需重新排序每个 Tablet 同步复制到对端 BE保证副本间顺序一致。存储层级分区粗粒度逻辑切片启用规划期裁剪并隔离 TTL/批量加载生命周期操作→ Tablet分区内按哈希/随机分桶、跨 BE 独立复制行按排序键物理有序→ MemTable约 96 MB 内存写缓冲落盘前按声明键排序保证每个磁盘 Segment 天然有序→ Rowset一次 flush、流式加载或压缩周期产生的不可变 Segment 束追加式设计支持并发摄入与无锁读→ Segment约 512 MB 自包含列式文件携带数据页与裁剪索引。Segment 文件内部自顶向下64 KB 列数据页Dictionary/RLE/Delta 编码默认 LZ4 压缩→ Ordinal 索引行序 → 页偏移→ Zone-map 索引每页与整个 Segment 的 min/max/has_null裁剪第一道防线→ Short-key前缀索引每约 1000 行一个、基于排序键前 36 字节的稀疏二分表支持毫秒级点查/范围查找→ Footer 与魔数各索引偏移与完整性校验StarRocks 仅内存映射尾部即可发现其余结构。读路径规划期分区裁剪dt BETWEEN谓词只打开匹配分区目录→ 规划期 Tablet 裁剪等值过滤含哈希分布列时计算目标 Tablet ID→ 前缀索引查找前导排序列定位精确 Segment/Page→ Zone-map 裁剪按 min/max 丢弃不命中谓词窗口的块→ 向量化扫描与延迟物化存活的列页顺序流过 CPU 缓存仅物化被引用的行与列。由于每次 flush 都以键序提交数据各裁剪层层层叠加最终实现数十亿行表上的亚秒级扫描。如何选择有效的排序键从工作负载洞察出发分析 Top-N 查询模式——等值谓词/IN列是理想的前导候选范围谓词时间戳、数值范围通常跟在等值列之后若范围列也出现在GROUP BY中将其前移可启用排序聚合高频 join/分组键也应考虑前置。同时度量基数高基数列数百万去重值裁剪效果最好。启发式规则顺序为高选择性等值列→主范围列→聚类辅助列低基数列放在高基数列之前可增强压缩宽度保持在 3–5 列过宽会拖慢摄入并撑爆 36 字节前缀索引限制过长的前导字符串列可能占满 36 字节前缀索引额度导致后续排序列无法被有效索引削弱前缀索引裁剪力、降低点查性能。与其他设计旋钮协同分区键应比前导排序列更粗例如PARTITION BY dateORDER BY (tenant_id, ts)让分区裁剪先移除整段日期范围、排序裁剪再处理内部分桶与排序使用相同列目的不同分桶保证集群内均匀分布排序实现 I/O 消除主键表默认以主键为排序键但也可附加列优化物理顺序聚合表与明细表遵循上述分析谓词驱动的排序键策略。参考模板场景分区排序键理由B2C 订单date_trunc(day, order_ts)(user_id, order_ts)多数查询先按用户、再按近期时间范围过滤IoT 遥测date_trunc(day, ts)(device_id, ts)设备维度时序读取占主导SaaS 多租户tenant_id(dt, event_id)分区实现租户隔离按天聚簇服务仪表盘维度查找无(dim_id)小表纯点查单列足矣分桶Bucketing哈希分桶还是随机分桶分桶是一份选择哈希分桶与随机分桶的速查指南。先看快速对比维度哈希分桶随机分桶示例DISTRIBUTED BY HASH(id) BUCKETS 16DISTRIBUTED BY RANDOM键声明必须HASH(col1, …)无——行按 round-robin 分配省略时的初始桶数创建时自动选择之后固定创建时自动选择设置 bucket_size 后可增长Tablet 拆分/收缩手动ALTER … BUCKETS自动拆分仅增长v3.2倾斜抵抗力取决于键基数高——设计上均匀桶裁剪✅过滤、join全 Tablet 扫描Colocate join✅本地聚合 / bucket-shuffle join✅支持的表类型全部仅明细Duplicate Key表哈希分桶行按一个或多个列的哈希值分配到 Tablet创建后 Tablet 数固定除非手动 ALTER。要求必须预先选择稳定、均匀、高基数的键——键基数通常应为 BE 节点数的 1000 倍以上以防范桶间数据倾斜初始桶大小应合理理想为 1–10 GB。优势查询局部性选择性过滤与 join 触碰更少 Tabletcolocate join事实表/维表共享哈希键实现高速 join可预测布局同键行始终落在一起本地聚合与 bucket-shuffle join跨分区哈希布局一致减少大 join 的 shuffle 开销。劣势数据分布倾斜时易出现热 TabletTablet 数静态扩容需维护 DDLTablet 不足会损害摄入、压缩与查询并行度Tablet 过多会膨胀元数据。实战示例维表-事实表 join 与 Tablet 裁剪-- 事实表按 (customer_id) 哈希分桶 CREATE TABLE sales ( sale_id bigint, customer_id int, sale_date date, amount decimal(10,2) ) ENGINE OLAP DISTRIBUTED BY HASH(customer_id) BUCKETS 48 PARTITION BY date_trunc(DAY, sale_date) PROPERTIES (colocate_with group1); -- 维表以相同键与桶数与 sales 表 colocate CREATE TABLE customers ( customer_id int, region varchar(32), status tinyint ) ENGINE OLAP DISTRIBUTED BY HASH(customer_id) BUCKETS 48 PROPERTIES (colocate_with group1); -- Tablet 裁剪仅访问单个 Tablet SELECT sum(amount) FROM sales WHERE customer_id 123; -- 本地聚合跳过 shuffle 聚合阶段 SELECT customer_id, sum(amount) AS total_amount FROM sales GROUP BY customer_id ORDER BY total_amount DESC LIMIT 100; -- Colocate join各 BE 本地配对 join无需网络 shuffle SELECT c.region, sum(s.amount) FROM sales s JOIN customers c USING (customer_id) WHERE s.sale_date BETWEEN 2025-01-01 AND 2025-01-31 GROUP BY c.region;何时使用哈希分桶模式稳定、分布过滤/join 键明确受益于桶裁剪的数仓负载需要 colocate join / bucket shuffle join / 本地聚合等特定优化使用聚合表或主键表。随机分桶行按 round-robin 分配、无需指定键设置PROPERTIES (bucket_sizebytes)后v3.2StarRocks 会随分区增长自动拆分 Tablet。优势零设计债无键、无桶计算写入抗倾斜磁盘与 BE 间压力均匀弹性增长Tablet 拆分保持摄入速度。劣势无桶裁剪每个查询扫描分区内全部 Tablet无 colocate join无键布局阻碍局部性目前仅支持明细表。何时使用日志/事件表或键会变化/倾斜的多租户 SaaS 表写入密集、均匀摄入吞吐至关重要的管道。运维指南随机分桶建议设置桶大小如 1 GiB以启用自动拆分哈希分桶需监控 Tablet 大小在 Tablet 超过 5–10 GiB 前重新分片。主键表Primary Key Tables实时更新的代价与取舍主键表使用 StarRocks 自研的新存储引擎核心优势是支持实时数据更新同时保持复杂 ad-hoc 查询的高效性能。实时业务分析中决策者可以基于最新数据实时分析缓解数据分析中的延迟问题。但主键并非免费的午餐——使用不当会造成不必要的资源浪费。选择主键索引类型主键索引Primary Index是主键表最关键的组件存储主键值与数据行位置之间的映射。目前支持三种类型全内存主键索引不推荐会造成显著内存浪费PROPERTIES ( enable_persistent_index false );本地磁盘持久化主键索引PROPERTIES ( enable_persistent_index true, persistent_index_type LOCAL );云原生持久化主键索引shared-data 弹性集群推荐PROPERTIES ( enable_persistent_index true, persistent_index_type CLOUD_NATIVE );官方明确不建议使用内存索引。若使用 shared-data弹性集群推荐云原生持久化主键索引与本地磁盘持久化索引不同它将完整索引数据存放于远端对象存储本地磁盘仅作缓存。相比本地磁盘持久化索引其优势是不依赖本地磁盘容量数据分片再平衡后无需重建索引。选择主键主键通常不帮助加速查询——可通过ORDER BY指定不同于主键的列作为排序键来加速查询。因此选主键时只需考虑导入与更新过程中的唯一性。主键越大消耗的内存、I/O 等资源越多因此一般建议避免选择过多或过大的列作为主键。主键默认最大 128 字节由be.conf中的primary_key_limit_size控制对应源码 be/src/common/config.h 中CONF_mInt32(primary_key_limit_size, 128)的默认值。可增大该值以支持更大的主键但需注意资源消耗上升。持久化索引空间占用估算存储空间(key size 8 bytes) * row count * 50%50% 为估计压缩效率实际取决于数据本身内存空间min(l0_max_mem_usage * tablet cnt, update_memory_limit_percent * BE process memory)。内存使用监控与调优主键表内存可通过 mem_tracker 监控// 查看整体内存统计 http://be_ip:be_http_port/mem_tracker // 查看主键表内存统计 http://be_ip:be_http_port/mem_tracker?typeupdate // 查看更详细的主键表内存统计 http://be_ip:be_http_port/mem_tracker?typeupdateupper_level4mem_tracker中的update项记录主键表使用的全部内存主键索引、delete vector 等也可通过指标监控服务如 Grafana观察。若对内存敏感、希望降低主键表导入过程的内存消耗可调整以下配置均在be.confl0_max_mem_usage (小于 104857600 的值默认 104857600) // Shared-nothing 集群 transaction_apply_worker_count (小于 CPU 核数的值默认为 CPU 核数) // Shared-data 集群 transaction_publish_version_worker_count (小于 CPU 核数的值默认为 CPU 核数)l0_max_mem_usage控制每个 Tablet 持久化主键索引的最大内存使用源码 config.h 默认 104857600 字节transaction_apply_worker_count与transaction_publish_version_worker_count均控制处理主键表 upsert/delete 的最大线程数。但需谨记降低l0_max_mem_usage可能增加 I/O 压力减少 worker 数可能拖慢数据摄入。压缩资源、数据新鲜度与查询延迟的三角权衡相比其他模型主键表在导入、更新、删除时需要额外的主键索引查找与 delete vector 生成操作引入额外资源开销因此需在以下三者间权衡压缩资源限制、数据新鲜度、查询延迟。数据新鲜度 查询延迟若既要更好新鲜度又要更好查询延迟意味着高频写入且需尽快压缩需要更多压缩资源// shared-data be.conf compact_threads 4 // shared-nothing be.conf update_compaction_num_threads_per_disk 1 update_compaction_per_tablet_min_interval_seconds 120可增大compact_threads、update_compaction_num_threads_per_disk或减小update_compaction_per_tablet_min_interval_seconds源码默认值见 config.h、config.h来投入更多压缩资源。如何判断压缩跟不上高频写入Shared-data 集群压缩跟不上会导致摄入变慢甚至写入失败。摄入变慢可通过show proc /transactions/{db_name}/running检查若 ErrMsg 出现Partitions compaction score is larger than 100.0, delay commit for xxxms. You can try to increase compaction concurrency说明发生摄入变慢若出现Failed to load data into partition xxx, because of too large compaction score...说明摄入已停止。Shared-nothing 集群无摄入变慢策略压缩跟不上会直接报错Failed to load data into tablet xxx, because of too many versions...。数据新鲜度 压缩资源受限压缩资源有限但需维持足够新鲜度就要牺牲部分查询延迟Shared-data 集群fe.conf调大lake_ingest_slowdown_threshold默认 100触发摄入变慢的压缩分数阈值与lake_compaction_score_upper_bound默认 2000触发摄入停止的阈值Shared-nothing 集群be.conf调大tablet_max_versions默认 1000源码见 config.h触发摄入停止的版本数阈值。增大这些配置可容纳更多小数据文件、降低压缩频率但会影响查询延迟。查询延迟 压缩资源受限想用有限压缩资源获得好查询延迟需要降低写入频率、以更大批次摄入数据具体做法参见各摄入方式章节降低摄入频率、增大批大小。查询调优Query Tuning自顶向下的五步闭环查询调优 是 StarRocks 实现高性能与高可靠性的关键。该目录汇集实用指南、参考资料与可落地的配方覆盖从编写 SQL 到解读执行细节的每个阶段。有效的查询调优遵循自顶向下流程识别问题检测慢查询、高资源占用或异常结果借助内置监控、查询历史与审计日志快速定位问题查询。参见 Query Tuning Recipes症状驱动诊断与 Query Profile Overview查询历史与 Profile。收集并分析执行信息用EXPLAIN或EXPLAIN ANALYZE获取查询计划开启并研读 Query Profile 获取详细执行指标。参见 Query Plan Overview、Explain Analyze Text-Based Profile Analysis 与 Query Profile Overview。定位根因找出耗时/耗资源最高的 Stage 或 Operator排查常见问题join 顺序欠佳、索引缺失、数据分布问题、低效 SQL 模式。参见 Query Profile Metrics 与 Query Tuning Recipes。应用调优策略SQL 改写加过滤、避免SELECT *Schema 调优加索引、换表型、调分区/聚类查询计划调优必要时用 hint 或变量引导优化器执行调优针对负载调会话变量。参见 Schema Tuning Recipes、Query Hint 与 Query Tuning Recipes。验证并迭代重跑查询、对比改动前后性能复查新计划与 Profile必要时重复。无论你是 DBA、开发还是数据工程师这套资源都能帮助你诊断并解决慢查询或资源密集型查询理解优化器选择与执行细节应用最佳实践与高级调优策略。Query Profile开启与获取Query Profile 记录查询涉及的所有工作节点的执行信息是诊断与调优的利器。开启方式SET enable_profile true; -- 会话级 SET GLOBAL enable_profile true; -- 全局级生产环境不建议长时间全局开启有额外开销可设置big_query_profile_threshold只捕获慢查询对应 FE 源码 SessionVariable.java 中的BIG_QUERY_PROFILE_THRESHOLD变量SET global big_query_profile_threshold 30s; -- 仅超 30 秒的查询 SET global big_query_profile_threshold 500ms; -- 仅超 500 毫秒 SET global big_query_profile_threshold 60m; -- 仅超 60 分钟长查询可用 Runtime Query Profilev3.1在执行期间按固定间隔上报默认间隔 10 秒可用SET runtime_profile_report_interval 30;调整。关键配置一览配置项类型合法值默认说明enable_profile会话变量true/falsefalse开启 Query Profilepipeline_profile_level会话变量1/211 合并指标2 保留原始结构禁用可视化工具runtime_profile_report_interval会话变量正整数10Runtime Query Profile 上报间隔秒big_query_profile_threshold会话变量字符串0s超过该时长的查询开启 Profile如 30s、500ms、60menable_statistics_collect_profileFE 动态true/falsefalse为统计信息收集相关查询开启 Profile获取方式Web UI 访问http://fe_ip:fe_http_port→ 顶部导航点击queries→ 在Finished Queries列表选择目标查询并点击Profile列链接或通过 SQL 函数get_query_profile配合last_query_id()获取最近查询 ID、show profilelist;列出近期查询与状态。自 v3.3.0 起INSERT INTO FILES()与 Broker Load 也支持 Query Profile。症状到修复按 Operator 的调优配方Query Tuning Recipes 提供症状 → 根因 → 已验证修复的实用手册。快速诊断流程先浏览执行概览QueryPeakMemoryUsagePerNode 80%或QuerySpillBytes 1 GB直接进入内存/溢写配方再在 Profile UI 按OperatorTotalTime %排序定位最热 Operator最后匹配各配方的特征指标模式再实施修复。以 Scan扫描Operator 为例存储引擎依次使用数据存储段内压缩编码数据多种索引、索引过滤Bitmap、Bloomfilter、Zonemap、ShortKey、NGram 索引跳过无关数据、谓词下推a 1类简单谓词推到列级求值、延迟物化仅从磁盘取所需列与过滤后的行、非下推谓词求值、投影表达式计算。常见瓶颈与对策包括冷/慢存储BytesRead/ScanTime/IOTaskExecTime占主导时换 NVMe/SSD 并启用 Data Cache按 BEdatacache_*与会话变量enable_scan_datacache配置过滤下推缺失PushdownPredicates接近 0 而ExprFilterRows高时改写为简单比较、避免%LIKE%与宽OR链或加 zonemap/Bloom 索引/物化视图线程池饥饿高IOTaskWaitTime伴低PeakIOTasks时扩容 Data Cache 与热存储Tablet 数据倾斜最大与最小OperatorTotalTime差距大时改用高基数列或增桶数Rowset/Segment 碎片化RowsetsReadCount/SegmentsReadCount暴涨时手动压缩并批量加载软删除累积DeleteFilterRows大时运行 BE 压缩清除。聚合AggregateOperator 方面StarRocks 依据查询模式与优化器决策采用多形态算法哈希聚合键可入内存、基数不极端SIMD 探测的紧凑哈希表、排序聚合输入已按 GROUP BY 键有序零哈希表成本高偏斜探测下常快 2–3 倍、可溢写聚合3.2哈希表超出内存限制时混合哈希/合并磁盘溢写分区防 OOM 且保持管道并行。分布式聚合为多阶段一阶段DISTRIBUTED BY是GROUP BY子集且分区共置局部聚合即最终结果、两阶段 localglobal典型分布式GROUP BY、三阶段 localshufflefinal重度DISTINCT与高基数GROUP BY、四阶段重度DISTINCT与低基数GROUP BY时增加阶段避免单点瓶颈。总结StarRocks 的高性能源于物理设计匹配查询模式这一原则的层层落实分区用粗粒度裁剪与元数据级生命周期操作换来 I/O 与运维成本的下降排序键通过在写路径上建立顺序、在 Segment 内构建微型索引让读路径上的每层裁剪互相叠加实现数十亿行表上的亚秒级扫描分桶在分区内部决定并行度与数据局部性哈希分桶换取裁剪/colocate/本地聚合能力随机分桶换取抗倾斜与弹性增长。主键表则以可控的索引内存与压缩资源为代价换来实时更新与复杂 ad-hoc 查询兼得的能力其三种索引形态与primary_key_limit_size、l0_max_mem_usage、tablet_max_versions等配置均可对照 be/src/common/config.h 中的真实默认值提供了精细的资源调节空间。最后查询调优用EXPLAIN/Query Profile 等工具支撑的五步闭环将上述设计决策与运行时行为连接起来形成设计-观测-调优-验证的完整方法论。继续深入可参阅分区、表聚类、分桶、主键表、查询调优概览、Query Profile 概览 与 Query Tuning Recipes。【免费下载链接】starrocksThe worlds fastest open query engine for sub-second analytics both on and off the data lakehouse. With the flexibility to support nearly any scenario, StarRocks provides best-in-class performance for multi-dimensional analytics, real-time analytics, and ad-hoc queries. A Linux Foundation project.项目地址: https://gitcode.com/GitHub_Trending/st/starrocks创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考