去年双十一，我负责的BI数据平台凌晨三点挂了。排查半天发现，是增量更新模式下，水印标记的日志表主键冲突直接把整个ETL链路干崩了。那天晚上我发现，很多同行遇到这个问题后第一反应都是“改主键生成策略”，但实际上我们面对的远不止是ID生成的单点问题，而是一个横跨上游业务库、中间抽取层、下游目标库的全链路设计缺陷。这篇文章我不会罗列所有可能的技术方案，而是把精力放在一件事上：帮你建立一张清晰的决策地图，你的主键到底是谁定义的、在哪个节点生成、由谁负责校验，然后给出在不同数据库选型、不同并发量级、不同一致性要求下的取舍路径。
我先把这个结论扔出来，不是要故作高深，而是因为过去五年里，我参与了十几个BI项目的增量ETL架构设计，踩过的坑告诉我一个规律：越是把主键冲突当成“数据库层面小问题”的团队，越容易在生产环境栽跟头。
日志表的主键冲突，本质上暴露了三个环节的责任模糊：（1）谁负责定义“一条日志记录的唯一标识”？（2）谁负责在写入前保证这个标识的全局唯一？（3）谁负责在冲突发生后兜底处理？如果你现在停下来想一想自己负责的系统，很可能发现这三个问题的负责人是模糊的，上游业务库觉得主键是他们的事，ETL开发觉得主键只是自增列随便设一下，DBA觉得冲突是应用代码的bug。
这种模糊导致的结果是：绝大多数团队在这件事上的投入顺序是反的。他们先去研究ON DUPLICATE KEY UPDATE怎么写，然后发现有些场景兜不住，再考虑换雪花算法，最后发现雪花算法也有时钟回拨的问题。正确的顺序应该是反过来：先把主键的定义权想清楚，再确定生成机制，最后用容错SQL做最后一道防线。
要理解主键冲突为什么会变成生产事故，必须先讲清楚水印标记在增量抽取中到底怎么工作。很多ETL开发用了两三年增量更新，但你要问他“水印值是在抽取前记录还是抽取后记录”，他未必能一口答上来，而这个问题恰恰是冲突概率的关键变量。
第一种是“抽取前取水印”。流程是这样的：ETL任务启动时，先去日志表查上次成功抽取的最大水印值（比如最大更新时间戳），记作last_watermark。然后用这个值去源表查询所有update_time > last_watermark的记录，拉取到目标库。拉取完成后，把本次抽取到的最大update_time写回日志表，作为下一轮增量的起点。
这种方式的优势是逻辑简单，但它有一个致命缺陷：如果在抽取过程中，源表还在持续写入新数据，那么本次抽取结束时记录的水印值，实际上比当时已经提交的数据的时间戳要小。这意味着下一轮抽取会把这些数据补上，不会丢数据。但问题在于，如果你用的是先插入日志表、再记录水印的流程，那么同一批数据可能在两轮抽取中被重复拉取，而日志表的主键如果基于抽取轮次加自增ID生成，就必然冲突。
第二种是“抽取后取水印”。ETL任务先查源表的最大update_time，记作current_max，再用上次的last_watermark到current_max之间的范围拉取数据。拉取完成后，把current_max写回日志表。这个方式精度更高，但它对抽取性能有影响，而且在高频写入场景下，current_max一直在变，你需要在事务内锁定这个值的边界。
我在一个日均300万条写入的电商订单场景里做过对比：抽取前取水印的方式，主键冲突概率约为每10万次抽取出现1.2次；而抽取后取水印加事务边界锁定后，冲突概率降到接近零。代价是单次抽取耗时增加了约15%。
很多人把日志表当成一个简单的“记录表”，但实际上日志表承载的是ETL任务的状态管理职能。它至少要记录这几项信息：抽取批次ID、水印起始值、水印结束值、抽取行数、抽取状态（成功/失败/部分成功）、开始时间和结束时间。
问题就出在“抽取批次ID”这个字段的生成方式上。如果你的日志表主键是自增ID，而你的ETL任务是多实例并行跑的，或者同一个任务因为失败重试而多次插入记录，自增ID就根本保证不了业务层面的唯一性，因为在失败重试的场景下，上一次插入的记录可能已经占用了某个自增ID，但你重试时需要知道“这一轮抽取”对应的唯一标识。
我在一个物流云仓的项目里遇到过这样的场景：ETL任务因为网络抖动超时，实际数据已经写到目标库了，但日志表更新状态失败。运维手动重跑任务后，源表的水印范围没变，于是同一批数据被再次拉取，日志表里出现了两条批次ID不同、但抽取范围完全相同的记录。如果下游有基于日志表做数据质量校验的任务，会直接报重复数据异常。
我给市面上常见的主键冲突解决方案做了一个分类框架，不是按技术名词分，而是按“主键的生成权在谁手里”分成三类：数据库负责生成、应用层负责生成、业务复合键作为主键。每一类的适用边界差异很大，选错了不只是性能问题，可能引发数据一致性问题。
自增ID是绝大多数团队起步时的选择，因为几乎零配置。但它的适用边界非常窄：只适用于单实例串行抽取、且不存在失败重跑造成日志重复的场景。
我能理解为什么很多团队不愿意放弃自增ID，它写性能好，B+树索引友好，查询效率高。但你要想清楚一个问题：你的ETL任务未来会不会变成并行抽取？如果会，自增ID在多实例写入同一张日志表时，ID的连续性断了不说，不同实例之间根本没法用自增ID来标识“我这一批数据的唯一性”。
序列机制（Sequence）在PostgreSQL、Oracle里比MySQL的自增ID要灵活，因为你可以按规则生成序列号，比如用年-月-日-批次序号拼出业务含义的主键。但序列也有自己的坑：如果序列缓存（cache）设置太大，数据库重启后序列值会跳号；如果设置太小，每次取序列号都是一次磁盘IO。我见过一个团队用Oracle序列做日志表主键，缓存设了1000，结果某次数据库异常重启后跳了800多个号，下游报表系统发现有800多天的数据“缺失”，实际上只是日志表ID不连续，数据本身一条没丢。
结论很简单：如果你的ETL是单实例串行、且接受日志表物理主键无业务含义，自增ID够用。但凡你设想过未来要并行、要跨库同步日志记录，果断放弃数据库层生成主键的思路。
雪花算法（Snowflake）是目前BI日志表主键生成的主流选择，我自己主导过三个项目的雪花算法落地。它的核心优势是把主键生成的职责从数据库层上提到应用层，让ETL代码控制主键的唯一性和趋势递增性。
但雪花算法在生产环境有四个坑，每个我都踩过：
（1）时钟回拨。雪花算法依赖机器时钟，如果服务器发生NTP时间同步导致时钟往回跳，就可能生成重复ID。美团的Leaf方案通过上报时间戳到ZooKeeper来解决这个问题，但这对BI团队的运维能力有要求。如果你没有ZooKeeper集群，最简单的兜底方案是：在ETL代码里做时钟回拨检测，一旦发现当前时间小于上次生成ID的时间，直接抛异常并熔断本次抽取，而不是试图用“等几毫秒”的方式糊弄过去。
（2）workId的分配。如果你的ETL是容器化部署，每次重启容器IP可能变，workId的自动分配就成了问题。我建议不要在代码里硬编码workId，而是用一个轻量的协调服务（比如Redis的INCR或者数据库的一张配置表）来动态分配。
（3）ID长度和索引效率。雪花算法生成的ID是19位的Long类型，在MySQL里用BIGINT存储没有性能问题，但如果你的日志表还需要和上游系统的INT类型业务ID做关联查询，注意索引命中率。我在一个日增500万条日志的场景里测试过，用雪花ID做日志表主键并用它关联业务表，查询耗时比用业务复合主键的方案高出约20%，因为BIGINT的索引体积更大。
（4）趋势递增≠绝对递增。雪花算法保证的是趋势递增，不是绝对递增。在多实例并行生成ID的场景下，后启动的实例生成的ID可能比先启动的实例小。如果你的日志表依赖主键的绝对递增来做某些假设（比如“ID大的一定是后写入的”），这个假设会被打破。
很少有人第一时间想到用业务复合键做日志表主键，因为我们习惯性地认为“日志表就该有一个自增ID”。但如果你能回答清楚“一条日志记录在业务上的唯一标识是什么”，往往意味着你对ETL任务的理解已经超出了“把数据搬过去”的层面。
业务复合键最常见的设计是：抽取日期加源表名加水印起始值加水印结束值。比如一个日志表的主键设计为extract_date、source_table、watermark_start、watermark_end四个字段的联合主键。这个设计的好处是：天然地、绝对地保证了一条日志记录在业务层面的唯一性，无论你用多少个并行实例抽取，无论你重跑多少次，只要这四个值不变，插入时就会直接触发唯一约束冲突，而不会静默地写入重复记录。
但它的代价也很明显：四个字段的联合主键占用的存储空间比一个BIGINT大，而且基于这个主键做查询时，必须带上所有字段才能利用索引。如果你只是按日期查日志，联合主键的第一个字段extract_date可以走索引；但如果你只按source_table查，索引就失效了。
我的取舍建议是：如果日志表的主要查询场景是按时间或按批次查，用雪花算法做主键，加一个业务复合唯一索引做冲突约束，两者各司其职。日志表的主键负责索引效率，唯一索引负责数据完整性。这不是过度设计，而是把一个职责拆成两个角色，各干各的。
说完了主键设计的三种路径，还要补充一个战术层面的能力，容错SQL。很多人以为在主键设计阶段就能完全杜绝冲突，但生产环境的复杂性决定了你需要一个兜底机制。我的态度很明确：容错SQL是最后一道防线，不是主键设计的替代品。
MySQL的ON DUPLICATE KEY UPDATE很容易被误用，因为它有一个反直觉的行为：当你执行INSERT语句时，如果主键或唯一索引冲突，MySQL不会报错，而是执行UPDATE子句，但前提是你不在UPDATE里修改触发冲突的那个键。
更隐蔽的问题是自增ID的消耗。即使触发的是UPDATE而非INSERT，MySQL也会消耗一个自增ID值。如果你的日志表同时有自增主键和业务复合唯一索引，而你的INSER语句总是触发唯一索引冲突然后走UPDATE，那么自增ID会快速跳号，用不了多久BIGINT也撑不住。正确的做法是：在这种情况下，不要给日志表设自增主键，直接用业务复合键做主键。
还有一个容易忽略的点：ON DUPLICATE KEY UPDATE的affected rows在冲突发生时会返回2（表示UPDATE了一行），而不是1。很多ETL监控逻辑用affected rows等于0来判断写入失败，这会在冲突场景下产生误报。务必修改监控逻辑，把返回值2也视为成功。
REPLACE INTO的处理逻辑是先DELETE后INSERT，这个“删除-插入”的过程在日志表里是灾难性的。因为DELETE操作会删除原有的整行记录，包括你可能关心的其他字段。如果你的日志表除了记录水印范围，还记录了抽取耗时、错误信息等，REPLACE INTO会导致这些信息在冲突发生时全部丢失。
更严重的是，DELETE操作会导致自增ID永久跳跃，而且对InnoDB的聚簇索引来说，删除旧记录再插入新记录，物理位置上可能完全不同，索引碎片化会更严重。我把这个结论写在这里：日志表场景下，永远不要用REPLACE INTO处理主键冲突。
前面聊的都是冲突发生前的设计预防和冲突发生时的技术兜底。这一节我想补上整个链条里最容易漏掉的一环，冲突发生后的监控和修复能力。很多团队把主键冲突当成一次性bug修完就过去了，但如果你没有建立三道防线，这个问题会反复出现。
这件事说起来简单，做起来很难。上游业务系统、ETL开发团队、DBA三方坐在一起开个会，讨论“日志表主键应该长什么样”，你会发现三方的理解可能完全不同：业务方觉得主键应该能追溯到源系统的业务ID；ETL觉得主键就是个技术字段别那么多要求；DBA只关心索引效率和存储成本。
我摸索出了一个实操方法：找三次历史上最严重的ETL故障复盘记录，从里面提取“如果当时主键设计是X，这个故障能不能避免”。这个方法的好处是，它不讨论抽象的主键设计哲学，而是把真实事故和主键设计直接关联起来。当一个报表负责人看着复盘材料说“上个月那次数据重复事故，如果我们日志表有业务复合唯一索引，根本不会发生”，主键设计的共识就自然形成了。
不要依赖人工发现主键冲突。你需要至少两个自动化检查点：
（1）ETL任务级别的行数校验。每次抽取完成后，比较源表的增量行数和目标库实际INSERT的行数。如果差值超过阈值（通常设5%），说明有重复插入被唯一约束拦截或被UPDATE替换。这个检查逻辑很简单，建一个通用的校验脚本就行。
（2）日志表级别的重复记录扫描。每天定时跑一个SQL脚本，按业务唯一约束的字段分组统计COUNT(*) > 1的记录。如果日志表只设了物理主键没有业务唯一约束，那就按抽取批次ID加水印范围做分组。这个扫描开销不高，但能让你在下一个ETL任务被阻断之前发现隐患。
当冲突已经发生，你手里通常有两件事要处理：第一是把因为冲突而未能写入的数据补进去；第二是搞清楚冲突的根因，防止下次再犯。
补偿写入的逻辑要根据冲突类型区分：如果是唯一索引冲突导致的INSERT被拒，你需要查出来被拒的那批数据，用UPDATE逻辑重新写入；如果是水印范围重复导致的重复记录，你需要对比两批数据的实际差异，确认是否存在数据版本覆盖问题。
我建议把修复脚本预置在ETL任务的异常处理模块里，不是等到出事再写。具体做法是：在日志表增加一个status字段，默认值success，冲突发生时写入一条status=failed的记录（此时需要走ON DUPLICATE KEY UPDATE更新status），然后有一个定时任务去扫描status=failed的记录，对它们对应的抽取批次做自动补偿。
不同数据库对主键冲突处理的语法和性能差异很大，你不可能拿着一套方案通吃所有环境。我在这三个数据库上都做过增量ETL的落地，下面给出差异化的建议。
MySQL不支持MERGE语句，也没有类似Oracle的序列跳过冲突的能力，所以MySQL环境下的主键冲突处理，本质上就是把业务复合唯一索引和ON DUPLICATE KEY UPDATE结合起来用。
但要注意唯一索引的性能影响：如果你用四个VARCHAR字段做唯一索引，单条索引记录可能超过100字节，在日增500万条的场景下，索引体积增长非常快。折中方案是把这四个字段做MD5哈希，用CHAR(32)存哈希值，然后给这个哈希列建唯一索引。缺点是发生冲突时你没法直接从哈希值反查原始字段，需要额外一次查询。
PostgreSQL的ON CONFLICT子句比MySQL的ON DUPLICATE KEY UPDATE语义更清晰。它支持指定冲突目标（conflict_target），你可以明确告诉数据库“当extract_date和source_table这个联合唯一索引冲突时做DO UPDATE”。
另外PostgreSQL支持DO NOTHING，冲突时直接跳过。这在日志表场景下非常有用：如果你的抽取任务幂等性足够好，且不想在日志表里覆盖旧记录，就用DO NOTHING。性能上DO NOTHING比DO UPDATE更快，因为不需要写UNDO日志。
Oracle的MERGE INTO语句功能最强大，但语法也最复杂。在日志表场景下，MERGE INTO的优势是可以在一条语句里同时处理INSERT和UPDATE逻辑，而且可以指定WHEN MATCHED和WHEN NOT MATCHED分别做什么。
但Oracle环境有一个容易被忽略的细节：如果日志表的唯一约束是基于函数索引（比如基于TRUNC(extract_date)），MERGE INTO的ON子句里必须写完全一致的表达式，否则Oracle不会走索引而走全表扫描。我在一个Oracle 19c的BI项目里遇到过这个坑，日志表3000万行，MERGE语句因为不走索引跑了6分钟，找到原因改掉后降到3秒。
这篇文章不是让你看完就结束的，而是希望你能拿着下面的清单去检查自己负责的系统。我尽量把每一项都写成可验证的动作，不做泛泛的建议。
（1）确认日志表主键的生成权在哪个层面。打开你的日志表DDL，看主键是自增ID、序列、雪花算法还是业务复合键。如果是自增ID，问自己一个具体问题：未来半年内ETL任务会不会变成并行抽取？
（2）确认日志表是否有业务层面的唯一约束。执行一条SQL：SHOW INDEX FROM your_log_table WHERE Non_unique = 0。如果结果只有主键那一行，说明你没有业务唯一约束。这是高风险的信号。
（3）确定业务层面的唯一标识组合。找一个最近发生过数据重复的案例做复盘，问：如果当时日志表有业务唯一索引，这个故障还能发生吗？用这个问题的答案来反向定义唯一键应该包含哪些字段。
（4）检查ETL任务的affected rows监控逻辑。找到你的ETL监控脚本，确认它是否把ON DUPLICATE KEY UPDATE返回值2也当作成功。如果不是，改掉。
（5）跑一次冲突扫描。用业务唯一键的分组查询，统计日志表里的重复记录。花10分钟跑一条SQL，结果可能让你发现埋了很久的隐患。
（6）评估是否需要把物理主键和业务唯一约束分离。如果你的日志表查询场景集中在按批次ID查，用雪花算法做主键；如果查询场景集中在按日期查，考虑用业务复合键做主键或至少建唯一索引。
主键冲突这件事的本质，不是技术难度有多高，而是太多团队把它当成“出一次bug修一次”的战术问题。如果你从头到尾把它当成一个需要拉通上游业务库、中间ETL层、下游目标库的系统设计问题，你会发现你做的不是一个主键设计，而是在给整个数据链路建一条清晰的底线。
我在做BI数据抽取时，用增量模式，每天从业务库捞取变化数据，用一个水印表记录last_modified。但时不时ETL任务报主键冲突，明明数据是新的，怎么会冲突？这个Bug排查了两天才发现原因，想彻底搞清楚原理。
这个问题我踩过两次坑。第一家公司用的是MySQL自增ID作为日志表主键，第二家改用雪花算法但仍然偶发冲突。
核心原因有三个：一是事务回滚，增量更新时，水印标记先写入日志表，但后续业务数据处理失败回滚，导致日志表主键ID被占用但数据未成功写入，后续批次再次使用同一自增ID生成（因为自增ID不会复用），若插入判断不严谨就会重复。
二是并发写入，同一水印批次内，多个线程同时写日志表，自增ID生成顺序不确定，但如果业务数据有重复的更新时间戳，日志表未做唯一约束，则可能插入多条相同逻辑行。三是水印时间精度不够，我见过用秒级时间戳作为水印，同一个秒内产生多条记录，日志表主键用自增ID，看起来不冲突，但实际业务主键重复。
根据我统计，80%的冲突来自第一种场景，15%来自第二种。我的建议：日志表不要用自增ID做主键，改用雪花ID + 业务唯一键联合索引，并在插入时使用ON DUPLICATE KEY UPDATE兜底。具体我们在第2条详细说。
我目前遇到了水印表主键冲突，查资料看到有几种方案：用REPLACE INTO、用ON DUPLICATE KEY UPDATE、或者用雪花ID。但不知道哪个最适合我的场景，我的数据量每天500万行，并发度中等。希望大佬能结合真实案例给出对比和选择建议。
我测试过四种方案，并在一家日均3000万行日志的公司落地过，分享我的决策树。方案一：REPLACE INTO，这是最粗暴的，先删后插，会导致主键跳跃和索引碎片。实测5分钟写入性能下降30%，且会丢失历史数据（比如你本来想记录操作时间，会被覆盖）。不建议用在带水印的日志表。
方案二：INSERT … ON DUPLICATE KEY UPDATE，只更新你需要的字段（如只更新时间戳），不更新payload。这比REPLACE安全，但要注意：必须确保业务唯一键（如order_id + event_type）要建立唯一索引。
性能上，碰撞率低于5%时几乎无影响，但碰撞率超过30%时写入耗时增加3倍。方案三：雪花ID作为业务主键，彻底避免自增冲突。但雪花ID依赖时钟同步，我遇到过时钟回拨导致ID重复的惨案（监控没做），后来加了NTP守护并预留回拨缓冲区。
方案四：使用数据库序列或全局ID服务，比如自建Leaf或UidGenerator，但引入新组件增加运维复杂度。我的选择：如果业务能容忍少量重复数据，就用方案二+雪花ID作为辅助；如果要求严格幂等，用方案三+方案二的兜底。
具体对比：方案二适合中小规模（<1000万行/天），方案三适合大规模且必须避免重复。
我想重新设计这个日志表，不想再被主键冲突折磨。目前考虑用业务字段（订单号+事件类型+时间戳）做联合主键，但担心性能；或者用UUID做主键，又怕太大。希望得到基于真实业务场景的建表建议，包括索引、字段选择、分区策略。
我从一个失败案例讲起：曾经为了省事，直接用自增ID做主键，每天跑批前删除前一天数据（分区）。结果某天增量跑了两次，第一天没删干净，第二天插入时全冲突。
后来重新设计，我给出的最佳实践如下： 表结构模板： `sql
CREATE TABLE watermark_log ( id bigint(20) NOT NULL AUTO_INCREMENT, -- 物理主键，仅用于内部关联 batch_id varchar(32) NOT NULL COMMENT '雪花ID或UUID，标记唯一批次', entity_id varchar(64) NOT NULL COMMENT '业务实体ID', event_type tinyint(4) NOT NULL, watermark_time datetime(3) NOT NULL COMMENT '水印时间，精确到毫秒', payload json DEFAULT NULL, created_at datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE KEY uk_batch_event (batch_id, entity_id, event_type), -- 业务唯一约束 KEY idx_watermark (watermark_time) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;关键点： 1. batch_id 用雪花ID保证全局唯一，作为业务层面的唯一键之一，而非自增ID。2. 联合唯一索引(uk_batch_event)直接拦截重复插入，这是防止冲突的终极防线。3. 主键 id 仍然自增，只用于InnoDB聚簇索引和普通关联，不影响业务逻辑。
水印时间加毫秒，避免一秒内重复。如果并发极高，可以考虑用序列号+时间戳。5. 分区：按watermark_time月分区，清理历史分区直接drop，不影响主键连续性。性能测试：5000万行数据，唯一索引命中碰撞率0.01%时，插入速度相比无唯一索引下降5%，可以接受。
如果你的写入TPS>5000，建议先检查数据源是否已经做了去重。
我的线上ETL任务偶尔报Duplicate entry错误，但无法及时发现，导致数据少跑几小时。我想在冲突发生时就告警，并且能自动重试或修复冲突记录。有没有成熟的监控方案和脚本示例？
我负责的一个数据平台每天运行300+个增量任务，冲突监控是我们用血的代价换来的。具体做法分两层： 一、主动监控（冲突发生前预警） – 在ETL调度框架中，每次写入日志表时，捕获MySQL的ER_DUP_ENTRY错误码（1062），并记录到专门的error_log表。
error_log表的冲突次数，如果超过阈值（比如10次/分钟），发钉钉/邮件告警。rows_affected与预期行数差值：增量更新通常返回受影响行数等于实际插入行数，如果差值大于0，说明存在update操作（即冲突走了兜底），需要人工排查是否重复。二、自动修复（冲突后补救） – 对于已经产生的冲突，一般是因为业务唯一键重复。自动修复脚本逻辑： 1. 找出违反唯一约束的行，按batch_id排序。2. 根据业务规则决定保留哪一条：通常保留watermark_time更晚的那条，或者保留created_at更早的那条（先入为主）。
执行DELETE FROM watermark_log WHERE id IN (冲突ID列表) AND id NOT IN (要保留的ID)。
然后解析ids，保留第一个（时间最新的），删除其余。注意：如果冲突量很大（比如超过1000行/分钟），建议先停掉写入任务，处理完再启动，避免死锁。实际效果：这套方案部署后，我们的数据丢失率从0.1%降到了0.001%，因为大多数冲突在1分钟内被自动清理。
只有冲突涉及跨批次业务逻辑时才会人工介入。
读者评论
作为负责过两个物流BI项目的ETL工程师，作者说的“责任边界模糊”太对了。我们之前主键冲突频频，每次都是DBA骂开发、开发怪业务，最后发现没人定义过日志表的业务唯一标识。后来我们强制要求每个抽取批次必须有batch_id+source_table的业务联合主键，冲突率直接降到零。建议想抄作业的团队，先把那个“谁定义、谁生成、谁校验”的决策地图画清楚，比埋头改SQL管用十倍。
文章对雪花算法的四个坑总结得很到位，尤其时钟回拨和workId分配，我踩过一模一样的。补充一点：如果用了雪花ID做日志表主键，记得在查询频繁的字段上加覆盖索引，否则BIGINT扫描确实比INT慢不少。另外，作者说的“趋势递增≠绝对递增”是个容易被忽视的陷阱，我们曾经有个实时看板依赖ID排序取最新记录，并行跑两个任务时后启动实例ID更小，导致数据延迟了几分钟。
作者拆解的三种方案里，我最欣赏业务复合键那个方向。很多人觉得日志表就该有自增主键，但在失败重跑、并行抽取场景下，自增ID根本承载不了业务语义。我现在给团队定的策略就是：日志表用业务复合键做主键（源表名+水印批次+时间戳），自动去重且无需额外容错逻辑。唯一要注意的是复合键字段长度，建议用哈希缩短，否则索引膨胀会影响写入性能。