多路归并本质是有序序列合并，依赖最小堆驱动的动态选择机制，而非if-else等分支结构；分支仅能静态路由，无法支撑K路流式、异构、可变长的持续归并。

直接用分支结构实现多路归并，无法真正处理高维异构时序数据库的变量指标数据。多路归并本质是“有序序列合并”，它不依赖分支逻辑，而依赖最小堆（优先队列）驱动的动态选择机制；所谓“分支结构”在这里属于概念混淆——if-else 分支只能做静态路由，无法支撑 K 路流式、可变长度、异构 schema 的持续归并。

核心前提：先对齐，再归并

高维异构时序数据（如 Prometheus 指标、IoT 设备传感器、金融行情快照）往往存在三重差异：

• 维度异构：同一指标在不同库中字段名不同（cpu_usage vs system.cpu.pct）、标签结构不同（label map vs flat key）、时间戳精度不同（ms vs ns）
• 序列无序性：单个数据库内部按写入时间有序，但跨库时间线可能错位、重叠、空缺，不能默认“各路首元素可比”
• 值类型混杂：数值型、字符串枚举（"UP"）、JSON 结构体、NaN/NULL 缺失标记共存

必须先完成统一建模：定义全局指标 ID（如 metric_id = hash(name, labels)），将各源映射为标准化的 (timestamp, value, source_id) 三元组流，并强制按 timestamp 升序预排序（或借助数据库游标保证单调递增读取）。

最小堆驱动的归并流程不可替代

对齐后的每路数据封装为 TimeSeriesReader 接口（含 hasNext() 和 next()），归并步骤如下：

• 初始化最小堆，每个节点存 (ts, value, source_id, reader_ref)，按 ts 小根排序
• 逐个 pop 堆顶 → 输出到目标时序存储（如 TSDB 写入 buffer 或 Kafka topic）→ 对应 reader 调用 next() 获取下一条；若 EOF 则不再入堆
• 遇到相同 ts 的多条记录：按业务策略合并（取均值 / 保留 source_id 最高者 / 拼接 JSON）而非简单覆盖

实战关键适配点

真实场景中需绕过纯数组思维，聚焦外部流控制：

• 延迟加载：不提前拉取整列数据，reader 的 next() 应触发一次 SQL 查询（SELECT * FROM t WHERE ts > last_ts ORDER BY ts LIMIT 1）或 HTTP 分页请求
• 空值与乱序容错：对 ts 为 null 或倒退的数据，跳过并打日志；设置滑动窗口（如 5s）缓存待定记录，避免因网络抖动导致误判
• 资源收敛：堆大小恒为 ≤ K（当前活跃数据源数），每路 reader 使用连接池+超时控制，避免某库响应慢拖垮整体
• 输出即持久化：结果不累积在内存 list 中，而是逐条写入压缩 Parquet 文件或调用 TSDB 批量写接口（如 InfluxDB Line Protocol 流式推送）

为什么不用分支结构模拟“多路选择”？

有人试图用嵌套 if-else 或 switch 匹配 source_id 来轮询各路，这在 K=3 时尚可读，但当接入 20+ 数据源（如混合云监控）时会迅速失控：

• 新增一路需改代码、重编译、重启服务，违背运维可观测性原则
动态启停某路（如临时下线故障数据库）无法热生效
• 无法处理某路长时间无新数据（饥饿）或突发高频写入（拥塞），缺乏统一调度节拍
• 时间对齐逻辑（如插值、降采样）无法在分支中统一注入，导致语义割裂