【避坑指南】从 MySQL 到 Apache Doris：自增主键的“隐藏陷阱”与数据迁移最佳实践-北京尧图网络

前言在从传统关系型数据库如 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 有着巨大差异。我们在享受其高并发、大吞吐的分析能力的同时也要注意避开这些“分布式特性”带来的小坑。希望这篇避坑指南能帮到正在做数据迁移的你如果你有更好的方案欢迎在评论区留言交流

【避坑指南】从 MySQL 到 Apache Doris：自增主键的“隐藏陷阱”与数据迁移最佳实践

相关推荐

JVM的简单认识

AI Movie Studio —— 一个面向电影、电视剧、动漫、短剧的 Agent 化影视理解与自动解说平台

热电偶信号滤波电路设计与工业应用实践

更多资讯

SpringBoot+LBS开发城市路线分享系统实践

SAP MRP运行参数配置与优化实战指南

buzz：基于Python与Markdown的极简开源博客系统

iPhone接入Windows：投屏与反控的技术本质区别

PDF与DOCX处理库选型及性能优化实战

水利数字化SCADA系统安全架构与国产化实践

今日更新

淘宝商品详情API开发实战与性能优化指南

Unity Package Manager刷新错误排查与解决方案

Java record 规范构造器能否被反序列化或反射绕过

本周精选

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

本月热门

面向复杂光照与角度的宠物面部识别鲁棒性增强策略

基于DRV8818与STM32的双极步进电机驱动方案实战解析

DRV8818PWPR+PIC18F45K80双极步进电机控制方案实战

读完文章，想聊聊您的网站？