大家好，我是小耶，写功课只是为了我踩过的坑，你们别再踩了！
时序数据库InfluxDB最经典的故障场景是什么？
不是磁盘写满，不是查询超时，而是内存突然爆了。
凌晨三点收到告警：InfluxDB内存使用率从40%飙升至98%，OOM Killer强制终止了进程。重启后跑了不到半小时，内存又满了。
这是高基数问题的典型表现。今天把从基数爆炸到OOM的完整链路彻底拆开讲清楚。
先搞懂几个词：
基数（Cardinality） ：标签维度取值组合的数量。method(10种) × endpoint(100种) × status(20种) = 20,000尚可接受，加入user_id(10万)后组合数飙升至20亿。
序列（Series） ：一个measurement + 一组标签值 = 一个序列。每个序列对应一条时间线。
TSM引擎：InfluxDB 1.x/2.x的存储引擎，为每个序列维护独立的内存索引项。
倒排索引：TSM引擎的核心索引结构，记录每个标签值对应哪些序列。基数越高，索引项越多。
OOM Killer：Linux内核的内存管理机制，在系统内存不足时强制终止占用内存最多的进程。
一、基数爆炸的数学逻辑
基数的计算方式是标签取值的笛卡尔积。
基数 = method取值数 × endpoint取值数 × status取值数 × ...
举例：
method = 10种 (GET, POST, PUT, DELETE, ...)
endpoint = 100种 (/api/users, /api/orders, ...)
status = 20种 (200, 404, 500, ...)
基数 = 10 × 100 × 20 = 20,000
20,000个序列，TSM引擎尚可应付。
但如果加入了user_id：
user_id = 100,000个
基数 = 10 × 100 × 20 × 100,000 = 2,000,000,000 (20亿)
20亿个序列，TSM引擎直接崩溃。
二、从基数爆炸到OOM的完整链路
第一步：序列数增长 → 内存索引膨胀
TSM引擎为每个序列在内存中维护一个索引项。20亿个序列意味着20亿个索引项。每个索引项需要存储measurement名、标签键值对、以及指向磁盘文件的指针。即使每个索引项只占100字节，20亿个索引项也需要200GB内存。
第二步：内存使用率飙升 → OOM Killer触发
InfluxDB的内存使用率在30分钟内从40%飙升至98%。Linux内核的OOM Killer检测到系统内存不足，强制终止了占用内存最多的进程——InfluxDB。
第三步：重启后TSM文件膨胀 → compaction失败
重启后，InfluxDB需要重新加载所有TSM文件的索引。如果TSM文件本身已经很大，加载过程会消耗大量内存，很快再次触发OOM。同时，后台的compaction任务需要合并小的TSM文件，但compaction本身也需要内存，形成恶性循环。
三、四步诊断法
第一步：查看当前基数
SHOW SERIES CARDINALITY
输出当前数据库的序列总数。如果超过100万，说明基数偏高；超过1000万，说明基数严重超标。
第二步：查看每个measurement的基数
SHOW SERIES CARDINALITY FROM measurement_name
定位到具体是哪个measurement贡献了最多序列。
第三步：查看每个标签的基数
sql
SHOW TAG VALUES CARDINALITY FROM measurement_name WITH KEY = "tag_name"
逐个标签查看取值数量。哪个标签的取值数最大，它就是高基数的元凶。
第四步：计算DISTINCT基数
对于疑似高基数的标签，可以直接计算它的DISTINCT值数量：
SHOW TAG VALUES FROM measurement_name WITH KEY = "user_id"
如果输出行数接近百万级，确认是高基数标签。
四、四种解决方案
方案一：高基数标识符放入field而非tag
这是最有效的解决方案。InfluxDB的tag会建立倒排索引，而field不建索引。
-- ❌ 错误：user_id作为tag
INSERT http_requests,user_id=12345,method=GET value=1
-- ✅ 正确：user_id作为field
INSERT http_requests,method=GET user_id=12345,value=1
代价是：无法通过WHERE user_id=12345快速过滤。如果业务需要按user_id查询，需要重新评估方案。
方案二：减少标签维度
评估每个标签是否真的需要作为tag。request_id、session_id、timestamp这类标识符通常不需要作为tag。
方案三：哈希分桶降维
如果user_id必须作为tag，可以对user_id做哈希分桶：
-- 将user_id哈希到100个桶
user_id_bucket = hash(user_id) % 100
用user_id_bucket作为tag，基数从10万降到100。
方案四：冷热分离
将高基数数据写入独立的measurement或数据库，设置较短的保留策略。高基数数据通常不需要长期保存。
五、KES时序组件的规避思路
KES的时序组件从内核层面规避了高基数陷阱。
第一，列式存储替代倒排索引。 时序组件采用列式存储，不维护每个序列的独立内存索引。标签值按列存储，查询时按列扫描，内存占用与数据量成正比，不与序列数成正比。
第二，时序与关系数据同一内核。 高基数标识符（如user_id）可以存储在关系表中，通过JOIN与时序数据关联。时序表只存储低基数标签，高基数维度通过关系表关联获取。
第三，原生支持时序与关系数据联合查询。 一条SQL可以同时查询时序指标和业务维度，不需要ETL搬运，也不需要维护两套系统。
六、小结
时序数据库InfluxDB高基数问题的根因是TSM引擎的内存索引机制——每个序列维护独立索引项，序列数增长直接导致内存膨胀。从基数爆炸到OOM有一条清晰的链路：序列数增长→内存索引膨胀→内存使用率飙升→OOM Killer触发→重启后再次OOM。四步诊断法可以定位高基数来源，四种解决方案可以缓解问题。KES时序组件通过列式存储和时序-关系融合架构，从内核层面规避了高基数陷阱。
小耶在手，SQL 不愁
还有什么想了解的，欢迎留言！小耶一定知无不言言无不尽……我们下次见~
