数据模型设计对查询性能的影响

很多人一遇到 OLAP 查询慢，第一反应就是「加索引」、「调参数」、「换硬件」。我见过太多团队，折腾了半天集群配置，结果发现罪魁祸首是表结构设计不合理。

说白了，数据模型是查询性能的根基。地基没打好，上层再怎么优化也白搭。这一章，我们就聊聊数据模型设计里那些最影响查询速度的坑，以及怎么避开它们。

2.1 宽表 vs 星型模型：一个经典选择题

先问个问题：你更习惯用宽表，还是用星型模型？

宽表就是把所有维度字段都塞进一张大表里。查询时不用 JOIN，看起来简单粗暴。但代价是什么？数据冗余、存储膨胀、更新困难。

星型模型则把事实表和维度表分开。事实表只存度量值和维度外键，维度表存描述性字段。查询时需要 JOIN，但数据一致性更好，存储更省。

我个人的习惯是：优先用星型模型。除非你的查询场景极其简单，且数据量很小，否则宽表迟早会出问题。

举个例子。假设你要分析电商订单数据：

-- 宽表设计（不推荐）
CREATE TABLE order_wide (
    order_id INT,
    user_name STRING,
    user_city STRING,
    user_level STRING,
    product_name STRING,
    product_category STRING,
    product_price DECIMAL,
    order_amount DECIMAL,
    order_time TIMESTAMP
);

-- 星型模型（推荐）
CREATE TABLE fact_order (
    order_id INT,
    user_id INT,
    product_id INT,
    order_amount DECIMAL,
    order_time TIMESTAMP
);

CREATE TABLE dim_user (
    user_id INT,
    user_name STRING,
    user_city STRING,
    user_level STRING
);

CREATE TABLE dim_product (
    product_id INT,
    product_name STRING,
    product_category STRING,
    product_price DECIMAL
);

你看，星型模型把用户信息和商品信息拆到了两张维度表里。查询时虽然要多写一个 JOIN，但数据更新时只需要改维度表，不用动事实表。这在数据量大的时候，维护成本差距非常明显。

2.2 分区与分桶：物理存储的「加速器」

数据模型设计不只是逻辑结构，物理存储策略同样关键。分区和分桶，就是最常见的两种手段。

分区是按某个字段（通常是时间）把数据切分成多个目录。查询时如果带上分区条件，引擎可以直接跳过大量无关数据。

分桶则是按某个字段的哈希值，把数据均匀分布到固定数量的桶里。适合做 JOIN 或聚合时的数据局部性优化。

我记得有一次，一个用户反馈说他们的日活查询要跑 5 分钟。我一看表结构，发现没有分区。加上按天分区后，查询时间直接降到了 30 秒。嗯，这就是分区的威力。

下面是一个 ClickHouse 中的分区和分桶示例：

CREATE TABLE event_log (
    event_date Date,
    event_time DateTime,
    user_id UInt32,
    event_type String,
    event_value Float64
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, event_type)
SAMPLE BY event_type;

这里按月份分区，按日期和事件类型排序。查询时如果指定了月份范围，引擎只会扫描对应的分区目录。

2.3 排序键与索引：数据布局的「导航图」

排序键决定了数据在磁盘上的物理顺序。好的排序键能让查询只扫描少量数据块，差的排序键则可能让查询全表扫描。

你想想看，如果数据按时间排序，那么查询最近一小时的数据时，引擎只需要读最后几个数据块。但如果数据是随机写入的，那每个查询都可能扫遍全表。

我遇到过最典型的案例：某团队把用户 ID 作为排序键，但查询全是按时间范围过滤的。结果每次查询都要扫描所有用户的数据，性能惨不忍睹。后来改成按时间排序，查询速度提升了 10 倍。

在 Apache Doris 中，排序键的定义方式如下：

CREATE TABLE sales_record (
    sale_date DATE,
    store_id INT,
    product_id INT,
    quantity INT,
    amount DECIMAL(12,2)
) ENGINE = OLAP
DUPLICATE KEY(sale_date, store_id)
DISTRIBUTED BY HASH(store_id) BUCKETS 10;

这里把 sale_date 和 store_id 作为排序键。查询时如果按日期和门店过滤，性能会非常好。

2.4 数据模型设计对查询性能的影响全景图

下面这张图，我把数据模型设计的关键要素和它们对查询性能的影响路径画了出来。你可以对照着检查自己的表结构。

2.5 常见数据模型设计误区

这些年我排查过不少慢查询，发现几个反复出现的模型设计问题。列出来给你参考：

误区	表现	后果	建议
过度使用宽表	一张表几百个字段	存储膨胀、更新慢、查询优化器难做下推	拆分为星型或雪花型
分区粒度不合理	按小时分区或不分区	小文件过多或扫描数据量过大	按天或按月分区
排序键与查询不匹配	排序键是 ID，查询按时间过滤	全表扫描，无法利用数据局部性	排序键选查询过滤字段
忽略数据倾斜	分桶字段选择不当	部分桶数据量巨大，查询变慢	选高基数字段做分桶
过度设计索引	给每个字段都建索引	写入变慢、存储膨胀	只给高频过滤字段建索引

2.6 总结

数据模型设计对查询性能的影响，怎么强调都不过分。逻辑模型选型决定了 JOIN 的复杂度，分区分桶决定了扫描的数据量，排序键和索引决定了数据访问的效率。

我曾经接手过一个项目，查询慢到用户想换数据库。结果我什么都没改，只是把宽表拆成了星型模型，加了分区和合理的排序键，查询速度提升了 8 倍。你看，有时候问题不在引擎本身，而在我们怎么组织数据。