4、复合索引策略：时间戳+标签的联合索引，前缀压缩与后缀截断技巧

时序数据库里，单列索引其实很少见。你想想看，查询条件往往是“某个标签在某个时间范围内”。这时候，时间戳+标签的联合索引才是主角。

我刚开始做时序平台时，犯过一个低级错误——给时间戳和标签分别建了独立索引。结果呢？查询走错索引，回表次数爆炸。后来才明白，联合索引的顺序、压缩、截断，每个细节都能让性能差出几个数量级。

4.1 联合索引的列顺序：谁在前？

先说结论：时间戳放前面，标签放后面。为什么？

• 范围查询优先：时间戳通常是范围查询（WHERE ts > '2024-01-01' AND ts < '2024-01-02'）。B+树索引最左前缀匹配，时间戳在前，能直接定位到起始位置，然后顺序扫描。
• 标签做过滤：标签一般是等值查询（WHERE tag = 'server01'）。放在时间戳后面，在时间范围内做精确过滤，效率极高。
• 避免随机IO：如果标签在前，时间戳在后，每个标签值都要去时间戳范围里扫一遍，随机IO剧增。

4.2 前缀压缩：把重复的标签值“压”在一起

时序数据有个特点：同一批写入的标签值高度重复。比如100万条数据，可能只有10个不同的标签。如果每条都存完整标签字符串，存储和索引都会膨胀。

前缀压缩就是干这个的。它把索引中相邻的、相同前缀的条目合并存储。举个例子：

原始索引条目（未压缩）：
ts=1000, tag='server01'
ts=1001, tag='server01'
ts=1002, tag='server01'
ts=1003, tag='server02'
ts=1004, tag='server02'

前缀压缩后：
ts=1000, tag='server01' (重复3次)
ts=1003, tag='server02' (重复2次)

我在项目中遇到过，一个标签列有200个不同值，但80%的查询只命中其中5个。前缀压缩后，索引体积缩小了60%，内存占用大幅下降。不过要注意：压缩率取决于数据分布。如果标签值完全随机，压缩效果就很有限。

4.3 后缀截断：别让长字符串拖垮索引

标签值有时候很长——比如URL、设备ID、JSON片段。如果整个字符串都塞进索引，B+树的节点能存下的条目数会急剧减少，树高度增加，IO次数飙升。

后缀截断就是只取字符串的前N个字符作为索引键。比如：

原始标签值：'device-abc-123-xyz-999'
截断前20字符：'device-abc-123-xyz'

嗯，这里要注意：截断长度太短，会导致索引选择性下降。比如截断到5个字符，'device' 和 'devic' 可能对应完全不同的设备，但索引认为它们一样，查询就会多扫描很多行。

截断长度	索引大小	选择性	适用场景
8字符	极小	低	标签值前8位唯一性高（如UUID前缀）
16字符	中等	中	常见设备ID、短名称
32字符	较大	高	URL、长描述、JSON片段
不截断	最大	最高	标签值极短（<10字符）

我曾经踩过一个坑：把设备MAC地址截断到6个字符，结果前6位全是厂商前缀，几乎没区分度。查询返回了10倍于预期的行数，然后回表过滤，性能直接崩了。后来改成截断12字符，问题解决。

4.4 联合索引的整体设计流程

把前缀压缩和后缀截断结合起来，完整的联合索引设计可以按以下步骤来：

1. 确定查询模式：分析慢查询，找出最常用的时间范围+标签组合。
2. 选择列顺序：时间戳在前，标签在后。如果多个标签，基数高的放前面。
3. 评估标签基数：基数低的启用前缀压缩，基数高的考虑后缀截断。
4. 测试截断长度：用实际数据跑 SELECT COUNT(DISTINCT LEFT(tag, N))，找到选择性拐点。
5. 监控索引膨胀：上线后观察索引大小和查询延迟，必要时调整压缩参数。

下面这张图展示了联合索引从原始数据到压缩截断后的完整结构：

4.5 实战中的取舍

前缀压缩和后缀截断不是银弹。我总结了几条经验：

• 写多读少场景：优先用前缀压缩，减少索引写入量。压缩计算在内存中完成，对写入延迟影响很小。
• 读多写少场景：后缀截断更合适。查询时索引选择性高，回表次数少。
• 混合负载：两者都用，但要设置合理的截断长度。我一般从16字符开始，用实际查询测试。
• 监控指标：关注索引命中率、平均回表行数、索引大小增长率。任何一个指标异常，都要重新评估策略。

说白了，复合索引设计就是一场平衡游戏——存储空间、写入性能、查询效率，三者不可能同时最优。我的建议是：先按默认策略上线，然后根据实际监控数据做微调。别一开始就追求完美，迭代优化才是正道。