StarRocks 深度剖析：全面兼容 MySQL 协议、CBO 优化器、主键模型与更新模型、物化视图与异步物化、Flink CDC 实时同步

StarRocks 这个引擎，我接触得比较晚，但上手之后确实有点「相见恨晚」的感觉。它不像 ClickHouse 那样剑走偏锋，也不像 Druid 那样重度预聚合。StarRocks 走的是「全能型」路线——既要高并发，又要实时更新，还要能跑复杂的 JOIN。

说白了，它想用一个引擎解决所有 OLAP 场景。今天我们就来拆开看看，它到底是怎么做到的。

全面兼容 MySQL 协议：降低接入成本

这一点我特别看重。你想想看，如果你的 BI 工具、数据开发平台、甚至命令行工具都能直接连，那得省多少事？

StarRocks 的 MySQL 兼容不是「半吊子」的。它支持 MySQL 5.5/5.7/8.0 的 wire protocol，也就是说，你用 MySQL JDBC 驱动、mysql-client、Navicat、DBeaver 都能直接连上去。

不过要注意，它兼容的是「协议层」，不是 SQL 语法全集。MySQL 的存储过程、触发器、自定义函数这些，StarRocks 是不支持的。但常用的 SELECT、INSERT、CREATE TABLE、JOIN、子查询，基本都能跑。

CBO 优化器：让查询不再「看天吃饭」

StarRocks 的 CBO（Cost-Based Optimizer）是我觉得它最「聪明」的地方。早期 OLAP 引擎大多用 RBO（Rule-Based Optimizer），规则写死了，遇到复杂查询经常选错执行计划。

CBO 的思路是：先枚举所有可能的执行计划，然后估算每个计划的代价（CPU、IO、网络），选最小的那个。

我记得有一次，一个同事写了个 8 张表 JOIN 的查询，在 ClickHouse 里跑了几分钟没出结果。换到 StarRocks 上，CBO 自动选择了 Broadcast Join + Colocate Join 的组合，20 秒就跑完了。

CBO 的核心流程大致如下：

主键模型与更新模型：实时更新的「杀手锏」

这是 StarRocks 和 ClickHouse 最大的区别。ClickHouse 的 UPDATE/DELETE 是「阉割版」的，性能差，还不支持事务。StarRocks 的主键模型（Primary Key Model）就是为了解决这个问题。

它的原理其实不复杂：底层用 LSM-Tree（Log-Structured Merge-Tree）结构，数据写入先写内存中的 MemTable，再定期刷到磁盘。主键去重和更新都在内存里完成，所以写入性能很高。

我举个例子，假设你有一个订单表，需要实时更新订单状态：

-- 创建主键模型表
CREATE TABLE orders (
    order_id BIGINT,
    user_id INT,
    status VARCHAR(20),
    update_time DATETIME
) PRIMARY KEY (order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 16;

-- 实时更新订单状态
INSERT INTO orders VALUES (1001, 201, '已发货', NOW());

-- 或者用 UPDATE 语法
UPDATE orders SET status = '已签收' WHERE order_id = 1001;

这里要注意，主键模型虽然支持实时更新，但也不是没有代价的。每次更新都会产生一个版本，如果更新太频繁，后台的 Compaction 压力会很大。

更新模型（Unique Key Model）和主键模型类似，但实现方式不同。更新模型用 Merge-on-Read 的方式，查询时合并多个版本的数据。主键模型用 Merge-on-Write，写入时就完成合并。所以主键模型的查询性能更好，但写入开销更大。

特性	主键模型 (Primary Key)	更新模型 (Unique Key)
写入方式	Merge-on-Write	Merge-on-Read
查询性能	高（无合并开销）	中等（需合并版本）
写入吞吐	中等（Compaction 压力）	高（延迟合并）
适用场景	高并发点查、实时更新	批量导入、低频更新

物化视图与异步物化：预计算的「双刃剑」

物化视图这东西，用好了是神器，用不好就是灾难。StarRocks 支持两种物化视图：同步物化视图和异步物化视图。

同步物化视图： 数据写入时自动更新，对查询透明。适合简单的聚合场景，比如 COUNT、SUM、AVG。

-- 创建同步物化视图
CREATE MATERIALIZED VIEW order_daily_stats AS
SELECT DATE(create_time) AS day,
       COUNT(*) AS order_count,
       SUM(amount) AS total_amount
FROM orders
GROUP BY DATE(create_time);

异步物化视图： 这是 StarRocks 3.0 之后引入的「大招」。它支持跨表 JOIN、多层嵌套、甚至 UNION ALL。更新策略可以手动刷新，也可以定时刷新。

我个人习惯把异步物化视图用在「多层汇总」的场景。比如先做一层明细汇总，再做一层维度汇总，最后做一层报表汇总。每一层都可以用异步物化视图来加速。

Flink CDC 实时同步：打通「最后一公里」

实时数仓的「最后一公里」是什么？就是从业务库（MySQL、PostgreSQL）到 OLAP 引擎的实时同步。StarRocks 和 Flink CDC 的配合，可以说是「天作之合」。

Flink CDC 能实时捕获 MySQL 的 Binlog 变更，然后通过 StarRocks 的 Stream Load 接口写入。整个过程是 Exactly-Once 语义，不会丢数据，也不会重复。

我去年做了一个项目，用 Flink CDC 把 MySQL 的 200 张表实时同步到 StarRocks，延迟控制在 3 秒以内。配置其实不复杂：

-- Flink SQL 示例
CREATE TABLE mysql_orders (
    order_id BIGINT,
    user_id INT,
    status STRING,
    update_time TIMESTAMP(3),
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'connector' = 'mysql-cdc',
    'hostname' = '192.168.1.100',
    'port' = '3306',
    'username' = 'cdc_user',
    'password' = '******',
    'database-name' = 'ecommerce',
    'table-name' = 'orders'
);

CREATE TABLE starrocks_orders (
    order_id BIGINT,
    user_id INT,
    status STRING,
    update_time TIMESTAMP(3),
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'connector' = 'starrocks',
    'jdbc-url' = 'jdbc:mysql://192.168.1.200:9030',
    'load-url' = '192.168.1.200:8030',
    'username' = 'admin',
    'password' = '******',
    'table-name' = 'orders',
    'sink.properties.format' = 'json',
    'sink.properties.strip_outer_array' = 'true'
);

INSERT INTO starrocks_orders SELECT * FROM mysql_orders;

总结一下，StarRocks 的这五个特性，其实解决了一个核心问题：让实时 OLAP 不再「割裂」。MySQL 协议降低了接入门槛，CBO 优化器保证了查询性能，主键模型支持了实时更新，物化视图加速了预计算，Flink CDC 打通了数据管道。五者结合，才构成了一个完整的实时数仓方案。