前言在从传统关系型数据库如 MySQL向现代分布式分析型数据库Apache Doris迁移的过程中很多开发者会习惯性地套用过去的经验。最近在处理一个数据迁移场景时遇到了一个非常经典且隐蔽的“坑”如何将一批“带 ID 的历史数据”和一批“不带 ID 的新增数据”合并导入到 Doris 中并保证 ID 连续且不冲突如果直接套用 MySQL 的自增主键逻辑在 Doris 中会遭遇严重的数据覆盖或 ID 冲突。今天我们就来深度扒一扒 Doris 自增列的底层逻辑并给出最优雅、高效的解决方案。一、 还原现场MySQL 习惯在 Doris 中翻车了1. 我们的预期MySQL 模式假设我们有两批数据需要导入到目标表第一批数据已经有现成的id1 到 1000。第二批数据没有id希望导入时自动从1001开始自增。在MySQL中我们的标准操作是创建带自增主键的表。显式插入第一批带id的数据。插入第二批不带id的数据。MySQL 在执行第 2 步时会自动将内部的自增计数器更新为1001即max_id 1因此第 3 步绝对不会发生冲突。2. Doris 中的惨烈翻车但在Apache Doris中如果你执行同样的操作就会发生灾难现象当你导入第二批不带id的数据时Doris 依然会从1或者它内部缓存的某个小数值开始自增分配 ID。后果如果你的表是Unique 模型新写入的数据会直接覆盖掉你第一批导入的历史数据如果你的表是Duplicate 模型表中会出现大量重复的 ID导致主键失去唯一性。二、 深度解析为什么 Doris 会“失控”参考doris官方描述要理解这个问题我们需要看一眼 Doris 的分布式架构。Doris 是一个分布式 MPP 数据库。为了在高并发、海量数据写入时保证高性能Doris 的自增列Auto-Increment采用了**“批量预分配Cache”**的机制FE 节点管理与缓存FE 负责管理自增 ID为了避免每次写入都去申请 ID 导致性能瓶颈FE 会一次性向 BE 节点分发一个 ID 缓存区间例如 1~10000。手动写入不触发更新当你通过INSERT语句显式指定 ID插入数据时Doris 的底层存储引擎会直接写入该值但它绝对不会去通知 FE 的自增计数器去更新它的 Cache 指针。无法手动修改起点Doris 目前不支持像 MySQL 那样通过ALTER TABLE tbl AUTO_INCREMENT x来手动指定自增起点。因此手动插入的 ID 和系统自动生成的 ID在 Doris 里是完全脱节的。三、 破局之法动态窗口函数法Best Practice既然 Doris 的AUTO_INCREMENT属性在混合导入场景下有这个限制我们该如何解决最佳实践放弃AUTO_INCREMENT属性利用 Doris 强大的 MPP 计算能力在导入时通过窗口函数动态生成 ID。这个方案不仅安全而且省去了创建临时表、合并表的繁琐步骤一步到位。实操步骤步骤 1创建普通目标表不带自增属性将id定义为普通的BIGINT类型。CREATETABLEtarget_table(idBIGINTCOMMENT唯一ID,nameVARCHAR(50)COMMENT姓名,create_timeDATETIMECOMMENT创建时间)ENGINEOLAPDUPLICATEKEY(id)DISTRIBUTEDBYHASH(id)BUCKETS10;步骤 2导入第一批历史数据带 ID直接将带有id的数据写入目标表。INSERTINTOtarget_table(id,name,create_time)SELECTid,name,create_timeFROMsource_batch_1;步骤 3获取当前最大 ID在导入第二批数据前查询一次当前表中的最大 ID。假设查询结果为9999。SELECTMAX(id)FROMtarget_table;步骤 4利用窗口函数动态计算并导入第二批数据在导入第二批不带 ID 的数据时利用ROW_NUMBER() OVER()窗口函数在最大 ID9999的基础上进行累加。INSERTINTOtarget_table(id,name,create_time)SELECT9999ROW_NUMBER()OVER()ASid,-- 在最大ID基础上动态累加name,now()ascreate_timeFROMsource_batch_2;四、 方案优势总结相比于“新建表1、新建表2、再合并”的传统套路这个方案有以下压倒性优势绝对安全零冲突完全不依赖 Doris 内部的自增生成器ID 连续性完全由 SQL 逻辑控制。极速迁移无 I/O 浪费Doris 的 MPP 架构对ROW_NUMBER()这种窗口函数做了极高并发的优化百万级数据瞬间即可完成 ID 计算并写入无需产生临时表落盘。极简运维全程只需操作一张目标表降低了迁移脚本的复杂度非常适合自动化 ETL 任务。五、 结语Doris 作为优秀的现代实时数仓在很多设计哲学上与传统的 MySQL 有着巨大差异。我们在享受其高并发、大吞吐的分析能力的同时也要注意避开这些“分布式特性”带来的小坑。希望这篇避坑指南能帮到正在做数据迁移的你如果你有更好的方案欢迎在评论区留言交流
