5. Doris索引全解｜前缀/ZoneMap/Bloom/Bitmap/倒排索引选型+实战调优

最新推荐文章于 2026-06-19 14:58:37 发布

原创最新推荐文章于 2026-06-19 14:58:37 发布 · 796 阅读

8 ·

本内容遵循CC 4.0 BY-SA版权协议

GEO检测

标签

#大数据 #Doris #OLAP #数据仓库

Doris 专栏收录该内容

16 篇文章

订阅专栏

专栏导语

本文是Apache Doris 原理实战系列第5篇，全程干货无废话！吃透Doris六大核心索引底层原理、生效规则、手写SQL+生产级最佳实践，告别盲目建索引、查询慢、存储膨胀踩坑问题。新手能看懂，大佬能落地，收藏常驻备查！

一、索引技术总体设计思想

Doris 的索引体系严格遵循 「存储计算协同」+「按需启用」 两大核心原则：
✅ 所有索引内嵌于列存Segment文件，无需搭建独立索引服务，运维零负担；
✅ 数据写入阶段自动构建索引，查询时执行引擎智能判定是否触发使用；
✅ 核心目标：极致减少磁盘I/O、快速跳过无关Data Page数据块，强化谓词下推效率。

📌 重点区分：Doris索引是轻量级、列级别、纯OLAP场景适配，和传统MySQL B+Tree行级索引完全不是一套逻辑，切勿混用设计思路！

二、前缀索引（Shortkey Index）｜默认零成本提速10倍

2.1 实现原理

基于表Sort Key（排序键）打造的稀疏轻量化索引：

默认每1024行采样一条排序键，聚合为单个逻辑Data Block；
每个数据块仅存1条索引项，上限36字节，取块内首行排序列前缀值；
特殊规则：遇到VARCHAR字符串列直接截断，未满36字节也不再追加后续列；
索引常驻Segment文件头部，体积极小，可全量缓存内存，类B+Tree快速检索；
粒度锁定数据块级，不精准定位单行，核心作用是批量过滤无效Block。

💡核心价值：WHERE条件命中排序键前缀，秒级锁定查询起止Data Page，批量裁剪数据。

2.2 创建与使用规则

🔹 创建逻辑：无需手动定义，建表时自动抓取DUPLICATE KEY/UNIQUE KEY前缀，限制36字节；单表Key唯一，仅能生成一组前缀索引。
🔹 触发规则：完全自动生效，无额外SQL语法。
🔹 效果核验：通过Query Profile查看RowsKeyRangeFiltered指标，直观看到前缀索引过滤行数，对比总数据量判断优化效果。

⚠️致命短板：查询条件不含排序键前缀列，稀疏索引直接失效！

2.3 适配场景

时间范围查询：event_time BETWEEN '2025-01-01' AND '2025-01-02'
Sort Key前缀列等值/IN精准查询
全表默认强制启用，不支持手动关闭

2.4 生产最优配置建议

高频WHERE过滤字段优先放入Sort Key，越常用越靠前；
字符串列后置放置，规避前缀截断浪费索引空间；
优先把Int整型列放首位，过滤效率远超字符串；
高基数、高区分度字段前置，快速批量筛除无效数据；
严禁低基数列（性别、状态）置顶，直接拉低索引区分度；
时间列首选首位，实现分区+索引双重数据裁剪；
实际生效最多抓取前3列，冗余Sort Key无意义。

三、ZoneMap索引（Min/Max索引）｜全员标配极简过滤

3.1 实现原理

纯元数据级轻量索引，零额外运维成本：

每个Data Page自动记录单列最小值/最大值，数值、日期、字符串全兼容；
存储分层：Segment Footer存整段最值，Page Header存单页最值；
占用极低：单页仅16~32字节，几乎无存储开销；
触发逻辑：遇到col > X / col < Y范围谓词，直接跳过最值不匹配的整页数据。

举例：某页age字段min=18、max=65，查询WHERE age>70，整页直接过滤，无需扫描。

3.2 适配场景

所有数值、时间、字符串列的常规范围查询
全表默认开启，无需手动创建
数据有序场景增益最大化，最值区间更紧凑

3.3 调优实操

无自定义配置参数，全程自动化；
核心优化：合理设计Sort Key，保证数据局部有序，压缩ZoneMap最值范围；
乱序导入（Kafka无序日志）后，手动触发Compaction重排序，恢复索引效率。

✅补充提醒：ZoneMap不支持等值查询，需搭配布隆/位图索引使用！

四、BloomFilter布隆索引｜高基数等值查询神器

4.1 实现原理

经典概率型索引，核心逻辑二选一：可能存在 / 一定不存在

为单列每个Data Page构建位数组+多哈希映射结构；
精准判定数据绝对不存在，快速过滤无效数据页，无法精准定位单行；
专属适配：高基数列等值、IN查询，拒绝Tinyint/Float/Double类型。

4.2 适配场景

✅ 推荐：user_id、device_id、url等高基数字符串列；= / IN精准匹配查询
❌ 禁用：范围查询、低基数列（误判率飙升，毫无增益）

4.3 建表&运维SQL（直接复制可用）

-- 建表时指定布隆索引
CREATE TABLE IF NOT EXISTS sale_detail_bloom (
-- 自定义字段
)
Duplicate KEY(...)
PROPERTIES (
"bloom_filter_columns" = "column_name1,column_name2"
);

-- 新增布隆索引
ALTER TABLE table_name SET ("bloom_filter_columns" = "column_name1,column_name2,column_name3");

-- 删除指定布隆索引
ALTER TABLE table_name SET ("bloom_filter_columns" = "column_name2,column_name3");

效果核验：查看Query Profile中RowsBloomFilterFiltered（过滤行数）、BlockConditionsFilteredBloomFilterTime（索引耗时）。

4.4 核心参数&最佳实践

核心参数	默认值	说明
bloom_filter_fpp	5%	误判率越低精度越高，占用存储空间越大
单页索引体积	~1KB/Page	受误判率、字段去重数影响

💡落地建议：

仅核心高基数字段启用，整体新增存储占比约10%；
低基数状态字段无需配置，浪费资源无收益；
误判不影响查询结果，仅多扫描少量数据页，安全稳定；
仅生效= / IN，≠、NOT IN、范围查询完全无效。

五、Bitmap位图索引｜低基数多维聚合秒杀

5.1 实现原理

专为低基数列打造的位运算索引：

字段每个唯一值对应独立Bitmap位图，标记每行数据归属；
支持高效AND/OR/NOT位运算，多维组合过滤性能拉满；
典型案例：gender字段M/F，分别生成独立位图，快速交叉筛选。

5.2 适配场景

低基数列（去重值＜1000）：地区、品类、业务状态
多维联合过滤：city='北京' AND category='数码'
搭配Bitmap字段，实现秒级UV去重统计

5.3 快速创建SQL

-- 新增位图索引
ALTER TABLE sales ADD INDEX idx_city (city) USING BITMAP;
-- Doris2.0+支持建表时直接声明

5.4 限制&落地避坑

仅支持：整型+≤50长度字符串，高基数列会导致索引体积爆炸；
存储开销大：最高可达原始数据20%-50%；
不适合高频更新Unique表，索引维护成本极高；
黄金组合：聚合模型+Bitmap_UNION，搞定海量数据UV统计。

六、倒排索引（Inverted Index）｜Doris2.0+全文检索专属

6.1 实现原理

借鉴搜索引擎Lucene架构，主打非结构化文本检索：

构建「关键词→行号列表」映射，支持模糊、全文、组合查询；
Doris2.1+优化自研轻量化结构，独立文件存储，不改动原数据；
性能代价：写入性能下降20%-50%，存储膨胀1.5~3倍。

6.2 适配场景

日志报错检索：message LIKE '%error%'
评论、描述类文本模糊匹配
替代低效全表扫描的前后模糊查询

6.3 建表示例（Doris2.1+直接用）

CREATE TABLE app_log (
    id BIGINT,
    msg TEXT,
    INDEX idx_msg (msg) USING INVERTED
) ENGINE=OLAP
DUPLICATE KEY(id);

6.4 支持检索语法

-- 全文匹配
SELECT * FROM app_log WHERE msg MATCH 'error timeout';
-- 前缀模糊查询
SELECT * FROM app_log WHERE msg LIKE 'err%';
-- 布尔组合筛选
SELECT * FROM app_log WHERE msg MATCH '+error -warning';