一、先搞懂两个核心概念：什么是实时分析，什么是CBO优化器
很多做数据开发的朋友，尤其是刚接触大数据的，可能会被“实时分析”和“CBO优化器”这两个词绕晕，咱们先掰开揉碎了说，绝对不搞玄乎的。
先讲实时分析：举个最常见的例子，你刷外卖平台，选好地址后，首页会立刻给你推附近3公里内的餐厅，还会按“好评高、配送快、价格合适”排序，这个“立刻”的动作就是实时分析——数据从产生（比如用户选地址、餐厅实时的好评数/配送时长）到得出结果，最多也就几秒，甚至毫秒级。如果这个过程要等10分钟，那用户早就走了，所以实时分析的核心要求就是“快”，而且得准。
再讲CBO优化器：CBO全称是基于成本的优化器，你可以把它理解成一个“路线规划师”。比如你要从家去机场，有三条路线：路线1是走高架不堵车但收费50块，20分钟到；路线2是走辅路不收费但可能堵车，40分钟到；路线3是走地铁不堵车但要转两次，30分钟到。CBO的作用就是，把每条路线的“成本”（时间、费用、换乘次数这些）算出来，选成本最低的那条。放到数据库里，就是你写一条SQL（比如“查附近3公里好评前10的餐厅”），CBO会算出不同执行方案的成本（比如先过滤3公里还是先按好评排序，是用索引还是全表扫），选最快的那个。
二、实时分析场景下，CBO的核心作用
实时分析对速度要求极高，慢个1秒用户体验就差很多，这时候CBO的作用就特别关键，核心体现在三个地方：
2.1 避免慢查询拖垮系统
实时分析的场景，比如外卖、电商的实时推荐、金融的实时风控，都是高并发的，可能一秒有几千条类似的SQL过来。如果没有CBO，每条SQL都用同一个执行方案，那很容易出现慢查询，比如本来可以用索引的，结果全表扫，直接把数据库拖死。CBO会给每条SQL选最优方案，把慢查询的概率降到最低。
2.2 应对数据的实时变化
实时场景下的数据是一直在变的，比如餐厅的实时配送时长、库存，用户的实时浏览行为，这些数据变了，原来的最优执行方案可能就不是最优的了。CBO会实时统计这些数据的分布（比如某类餐厅的配送时长普遍是10分钟还是30分钟），动态调整执行方案，保证速度。
2.3 优化复杂SQL的执行效率
实时分析经常要写复杂的SQL，比如“查过去1小时内，下单金额超过100的用户，在下单前10分钟内浏览过的商品，按商品的实时销量排序”，这种SQL有多个过滤、关联、排序的步骤，CBO会把这些步骤的顺序调整得最合理，比如先过滤下单金额超过100的用户，再关联浏览记录，最后排序，避免做无用功。
三、StarRocks中CBO的具体应用（附完整示例）
StarRocks是专门为实时分析设计的数据库，它的CBO做了很多优化，特别适合高并发、低延迟的场景。咱们用一个具体的外卖场景来演示，所有示例用StarRocks的SQL（也就是MySQL兼容的语法，很容易懂），先把场景和表结构说清楚。
3.1 场景准备
咱们要做的实时分析需求是：给用户展示附近3公里内，过去1小时内好评数增加超过5的餐厅，按“好评数+配送速度”排序，取前10个。
首先，我们需要两张表：一张是餐厅的实时信息表（存储餐厅的位置、实时好评数、实时配送时长），一张是餐厅的实时更新表（存储过去1小时内餐厅的好评数变化）。
先建表，StarRocks的表结构和MySQL类似，只是多了一些实时优化的配置：
-- 建餐厅实时信息表
CREATE TABLE restaurant_info (
restaurant_id INT COMMENT '餐厅ID',
restaurant_name VARCHAR(100) COMMENT '餐厅名称',
longitude DOUBLE COMMENT '经度',
latitude DOUBLE COMMENT '纬度',
realtime_good INT COMMENT '实时好评数',
realtime_delivery DOUBLE COMMENT '实时配送时长（分钟）',
update_time DATETIME COMMENT '更新时间'
) ENGINE=OLAP
DUPLICATE KEY(restaurant_id)
COMMENT '餐厅实时信息表'
PARTITION BY RANGE(update_time) (
PARTITION p20240501 VALUES LESS THAN ('2024-05-02'),
PARTITION p20240502 VALUES LESS THAN ('2024-05-03')
)
DISTRIBUTED BY HASH(restaurant_id) BUCKETS 10
PROPERTIES (
"replication_num" = "1", -- 副本数，测试环境设为1
"in_memory" = "true" -- 实时数据放内存，加速查询
);
-- 建餐厅实时更新表
CREATE TABLE restaurant_update (
restaurant_id INT COMMENT '餐厅ID',
good_increase INT COMMENT '过去1小时好评数增加量',
update_time DATETIME COMMENT '更新时间'
) ENGINE=OLAP
DUPLICATE KEY(restaurant_id, update_time)
COMMENT '餐厅实时更新表'
PARTITION BY RANGE(update_time) (
PARTITION p20240501 VALUES LESS THAN ('2024-05-02'),
PARTITION p20240502 VALUES LESS THAN ('2024-05-03')
)
DISTRIBUTED BY HASH(restaurant_id) BUCKETS 10
PROPERTIES (
"replication_num" = "1",
"in_memory" = "true"
);
然后插一点测试数据，模拟实时数据：
-- 插餐厅实时信息表数据
INSERT INTO restaurant_info VALUES
(1, '川菜馆', 116.3972, 39.9075, 100, 15, '2024-05-02 12:00:00'),
(2, '粤菜馆', 116.3980, 39.9080, 120, 12, '2024-05-02 12:00:00'),
(3, '火锅店', 116.3990, 39.9090, 90, 18, '2024-05-02 12:00:00'),
(4, '面馆', 116.4000, 39.9100, 80, 10, '2024-05-02 12:00:00'),
(5, '奶茶店', 116.4010, 39.9110, 150, 8, '2024-05-02 12:00:00');
-- 插餐厅实时更新表数据
INSERT INTO restaurant_update VALUES
(1, 6, '2024-05-02 12:00:00'),
(2, 3, '2024-05-02 12:00:00'),
(3, 7, '2024-05-02 12:00:00'),
(4, 2, '2024-05-02 12:00:00'),
(5, 10, '2024-05-02 12:00:00');
3.2 写符合需求的SQL，看CBO的执行效果
现在我们写SQL，要实现的需求是：用户的位置是经度116.3972，纬度39.9075（也就是餐厅1的位置），查附近3公里内，过去1小时好评数增加超过5的餐厅，按“实时好评数 - 实时配送时长”排序（好评越多、配送越快，得分越高），取前10个。
首先，我们需要一个计算两个经纬度之间距离的函数，StarRocks有内置的st_distance函数，直接用：
-- 完整的查询SQL
SELECT
ri.restaurant_id,
ri.restaurant_name,
ri.realtime_good,
ri.realtime_delivery,
ru.good_increase,
-- 计算距离，单位是米，转成公里除以1000
st_distance(point(ri.longitude, ri.latitude), point(116.3972, 39.9075)) / 1000 AS distance
FROM restaurant_info ri
-- 关联实时更新表，只取过去1小时的更新
JOIN restaurant_update ru
ON ri.restaurant_id = ru.restaurant_id
AND ru.update_time >= NOW() - INTERVAL 1 HOUR
-- 过滤条件：距离3公里内，好评增加超过5
WHERE
st_distance(point(ri.longitude, ri.latitude), point(116.3972, 39.9075)) / 1000 < 3
AND ru.good_increase > 5
-- 排序：得分越高越靠前
ORDER BY (ri.realtime_good - ri.realtime_delivery) DESC
LIMIT 10;
现在我们用StarRocks的EXPLAIN命令，看CBO给这条SQL选的执行方案：
EXPLAIN ANALYZE SELECT
ri.restaurant_id,
ri.restaurant_name,
ri.realtime_good,
ri.realtime_delivery,
ru.good_increase,
st_distance(point(ri.longitude, ri.latitude), point(116.3972, 39.9075)) / 1000 AS distance
FROM restaurant_info ri
JOIN restaurant_update ru
ON ri.restaurant_id = ru.restaurant_id
AND ru.update_time >= NOW() - INTERVAL 1 HOUR
WHERE
st_distance(point(ri.longitude, ri.latitude), point(116.3972, 39.9075)) / 1000 < 3
AND ru.good_increase > 5
ORDER BY (ri.realtime_good - ri.realtime_delivery) DESC
LIMIT 10;
EXPLAIN ANALYZE的结果里，我们能看到几个关键信息：
关联顺序：CBO先扫描restaurant_update表，过滤出good_increase>5的记录（只有3条：餐厅1、3、5），然后再和restaurant_info关联，这样关联的数据集很小，速度快。如果反过来，先扫restaurant_info再关联，数据集是5条，虽然差得不多，但如果restaurant_info有10万条，差距就大了。
过滤顺序：CBO先过滤update_time，再过滤good_increase，因为update_time的过滤条件是范围，能快速缩小数据集。
排序优化：CBO发现排序后要取前10，所以会在排序的时候只保留前10的结果，不用排完所有数据再取，节省时间。
四、StarRocks中CBO的调优策略
CBO虽然聪明，但也不是万能的，很多时候需要我们手动调优，让它选的方案更合理。下面是几个常用的调优策略，都是实战中验证过的。
4.1 给表加合理的统计信息
CBO选方案的依据是表的统计信息，比如表有多少行、某列的最大值最小值、某列有多少个不同的值。如果统计信息不准，CBO就会选错方案。
比如，restaurant_info表有10万行，但统计信息显示只有1万行，CBO可能会选全表扫，而实际上应该用索引。
StarRocks的统计信息是自动收集的，但有时候需要手动更新，尤其是数据量变化大的时候：
-- 更新restaurant_info表的统计信息
ANALYZE TABLE restaurant_info;
-- 查看统计信息是否更新
SHOW TABLE STATS restaurant_info;
4.2 优化表的结构和索引
CBO的能力再强，如果表结构不合理，也发挥不出来。比如，实时分析的表，应该用合适的分区和分桶：
分区：按时间分区，比如每天一个分区，查询的时候只扫当天的分区，不用扫历史数据。
分桶：按关联键分桶，比如restaurant_info和restaurant_update都按restaurant_id分桶，关联的时候不用跨节点，速度快。
另外，实时分析的表，应该用内存表（in_memory = "true"），把热点数据放内存，减少磁盘IO。
4.3 优化SQL的写法
很多时候，CBO选错方案，是因为SQL写得有问题，比如：
不要在过滤条件里用函数，比如WHERE YEAR(update_time) = 2024，这样CBO没法用update_time的索引，应该改成WHERE update_time >= '2024-01-01' AND update_time < '2025-01-01'。
尽量用小表关联大表，CBO会优先扫描小表，缩小关联的数据集。
不要写复杂的子查询，尽量用JOIN代替，CBO对JOIN的优化比子查询好。
比如，把下面这条有问题的SQL：
SELECT * FROM restaurant_info WHERE YEAR(update_time) = 2024;
改成：
SELECT * FROM restaurant_info WHERE update_time >= '2024-01-01' AND update_time < '2025-01-01';
4.4 调整CBO的参数
StarRocks有一些CBO的参数，可以根据场景调整，比如：
cbo_join_order：控制CBO是否自动调整关联顺序，默认是true，高并发场景下可以保持打开。
cbo_limit_pushdown：控制CBO是否把LIMIT推到前面，默认是true，适合取前N条的场景。
cbo_statistics_sample_rate：控制统计信息的采样率，数据量特别大的时候，可以把采样率调大，让统计信息更准。
调整参数的方法：
-- 调整CBO的参数，只对当前会话有效
SET cbo_join_order = true;
SET cbo_limit_pushdown = true;
SET cbo_statistics_sample_rate = 0.1; -- 采样率10%
五、CBO优化器的优缺点和注意事项
5.1 优点
自适应：能根据数据的实时变化，自动调整执行方案，适合实时分析场景。
优化复杂SQL：能把复杂的SQL拆解成最优的执行步骤，不用开发者手动优化。
提升系统稳定性：减少慢查询的概率，避免系统被拖垮。
5.2 缺点
依赖统计信息：如果统计信息不准，CBO会选错方案，反而变慢。
有一定的开销：CBO在选方案的时候，会花一点时间计算成本，对于特别简单的SQL，可能会增加一点延迟。
对开发者的要求高：虽然CBO能优化SQL，但如果SQL写得太差，CBO也无能为力。
5.3 注意事项
定期更新统计信息：尤其是数据量变化大的时候，比如每天导入大量数据后，手动更新统计信息。
不要过度依赖CBO：对于特别复杂的SQL，还是要自己检查执行方案，比如用EXPLAIN ANALYZE看CBO选的方案是否合理。
测试环境和生产环境的统计信息要一致：如果测试环境的表数据量和生产环境差很多，CBO在测试环境选的方案，在生产环境可能不适用。
六、总结
实时分析场景下，CBO优化器是StarRocks的核心能力之一，它能帮我们自动选最优的执行方案，保证查询速度。但CBO不是万能的，需要我们合理建表、优化SQL、定期更新统计信息，才能发挥它的最大作用。
对于刚接触大数据的朋友，不用怕搞不懂CBO，只要记住它是一个“智能路线规划师”，我们要做的就是给它提供准确的“路况信息”（统计信息）和合理的“起点终点”（SQL和表结构），它就会给我们选最快的路线。