作者：谢望舒-638｜5 年中间件研发｜方向：消息中间件与数据一致性 栈：MySQL 8.0.32（InnoDB）、Kafka 3.4、Spring Boot 3.2、Go 1.21 消费侧 场景：订单域支付回调幂等表，日均约 37 万条，单表 40GB
一、现象：一次「重复执行」事故，根因却查了 6 小时
先摆数字。某天 02:24–02:41 的 17 分钟窗口内，对账系统报出 372 笔重复执行（其中 11 笔是支付回调类，其余是营销发券类），下游不得不走应急冲正。
诡异的地方在于：监控上重复键命中率（affected_rows=0 占比）只从基线 2.1% 微涨到 2.4%，幂等表看起来「工作正常」；而消费侧日志里一条 ERROR 都没有。我们最初怀疑的是 rebalance 重放（at-least-once 本来就会重复），排查了一夜没对上——因为这些消息在 broker 侧根本没有重投，__consumer_offsets 的 offset 是单调递增的。
真正的根因 6 小时后才被一个不起眼的 diff 揭穿：上游 SDK 从 2.9 升到 3.1 后，trace_id 的生成规则从 32 位 UUID 变成了「服务名-集群-序号」的拼接串，长度最长 46 字符；而我们幂等表的 idem_key VARCHAR(32) 装不下。
二、根因：INSERT IGNORE 的「错误降级」语义，把两种完全不同的失败合并成了同一个 affected_rows
这是这次事故里最反直觉的一层，值得单独讲透。
INSERT IGNORE 的官方语义是：把可忽略的 error 降级为 warning，然后跳过该行。问题在于，「可忽略的 error」范围比大多数人的直觉宽得多——它不止 1062（Duplicate entry），还包括：
- 1406 Data too long for column（数据截断）
- 1265 Data truncated for column（非严格模式下的值转换失败）
- 1366 Incorrect value、外键约束失败等
于是在我们的链路里，一次「键太长被截断」的插入，最终表现和一次「真正的重复键」完全一样：affected_rows = 0，无异常、无日志、事务正常提交。
更阴的是截断的方向。VARCHAR(32) 会取前 32 个字符。上游新格式是「服务名-集群-序号」，前缀（服务名+集群）是同一批消息共用的，变化的部分恰恰在 32 位之后。也就是说：本应互不相同的 372 个幂等键，截断后全部塌缩成了同一个短键——第一条插入成功（affected_rows=1），后面 371 条全部 affected_rows=0，被当成「重复」跳过……
等等，这里有个反转，才是事故真正发生的机制：我们的业务代码里，幂等键不是用来「跳过」的，而是用来「查询业务流水」的。消费逻辑是「先 INSERT IGNORE 占位，再用这个 key 去查业务流水表决定是否放行」。截断后的短键在流水表里查不到任何记录 → 代码走了「查不到 = 首次」分支 → 372 条消息全部被放行执行。幂等表不但没拦住，反而因为「插入成功」给了下游一个错误的信心。
打个比方：幂等键就像快递单号，你把它后三位撕掉再录入系统，10 个不同包裹就都登记成了同一个单号。你以为在「查重」，其实在「合并」。
三、具体做法：四步修复，全部可复现
第 1 步：先确认你的字符集，别想当然
VARCHAR(n) 的 n 是字符数，不是字节数：
SELECT column_name, character_maximum_length, character_set_name
FROM information_schema.columns
WHERE table_name = 'idem_record' AND column_name = 'idem_key';
utf8mb4 下 VARCHAR(32) 能装 32 个中文或 32 个 ASCII，但上游给的 46 位 ASCII 串照样溢出。很多人默认「UUID 32 位 = VARCHAR(32) 刚好」，一旦键的生成方换了实现，这个「刚好」就是定时炸弹。
第 2 步：把键长度按「协议上限 + 余量」设计，而不是按「当前样例」
幂等键是跨系统契约，长度必须写成接口文档里的硬约束（我们定的是 ≤128 字符，DB 列 VARCHAR(128)），并且：
-- 应用侧入库前强制校验，超长直接 fail-fast，绝不截断
if (idemKey.length() > 128) {
throw new IdemKeyTooLongException(idemKey); // 让异常炸出来，别静默
}
第 3 步：用「显式 INSERT + 捕获 1062」替换 INSERT IGNORE
try {
jdbc.update("INSERT INTO idem_record (idem_key, biz_id, created_at) VALUES (?,?,NOW())",
idemKey, bizId);
// 插入成功 → 首次
} catch (DuplicateKeyException e) {
// 只有 1062 才会走到这里；1406 等其他错误会原样抛出，不会被吞
// 走「重复」分支
}
差别在哪？INSERT ... ON DUPLICATE KEY UPDATE 和 INSERT IGNORE 都会把 1406 降级成 warning；而普通 INSERT 遇到 1406 会抛 SQLException——错误被「大声」暴露，而不是被「安静」合并。我们统计过，普通 INSERT 的唯一额外成本是重复键时的异常路径，在我们 2.1% 的重复率下，P99 增加 <0.8ms，完全可接受。
第 4 步：加一条「回读校验」，防截断类静默失败
对资金类链路，占位插入后再回读一次确认键原样落库：
String stored = jdbc.queryForObject(
"SELECT idem_key FROM idem_record WHERE idem_key = ? AND biz_id = ?",
String.class, idemKey, bizId);
if (stored == null || !stored.equals(idemKey)) {
// 键被改动过（截断/编码转换）→ 告警 + 拒绝放行
log.error("idem_key integrity broken: expect={} stored={}", idemKey, stored);
alarm("IDEM_KEY_INTEGRITY");
throw new IllegalStateException("idem key mismatch");
}
这条回读在我们 37 万/天的量级下 P99 增加约 0.4ms（InnoDB 唯一索引点查），换来的是「键被静默改动」从不可见变成秒级告警。
四、踩过的坑与反直觉清单
- affected_rows=0 是「歧义信号」：在 INSERT IGNORE 语义下，它同时表示「真重复」和「插入失败被降级」，业务代码却只能二选一。任何用 affected_rows 做分支判断的幂等实现，默认都在赌「不会有第二类失败」。
- utf8mb4 下截断按字符、但上游长度按字节/字符混用：我们一次预发联调里，上游按字节算长度（≤128 字节），实际发出 90 个英文字符 + 3 个 emoji（12 字节），DB 列 VARCHAR(120) 装得下字符数却装不下……这类边界只出现在 emoji/多字节混排的消息里，压测数据全是 ASCII 永远测不出来。
- 监控看不到：MySQL 侧
SHOW GLOBAL STATUS LIKE 'Com_insert'计数正常，慢查询日志为空（这条 INSERT 只花了 0.2ms），binlog 里能看到键被截断——binlog 是这次事故里唯一留下真相的地方，我们后来把「幂等键长度分布」做成了 Grafana 面板，直接读业务库MAX(CHAR_LENGTH(idem_key))每小时聚合。 - 不要靠「上游保证不超 32 位」：任何跨系统的长度约定，落库方必须自己校验 + 自己 fail-fast，把「信任」换成「检查」。上游 SDK 升个次版本就能让约定失效，这次事故里 2.9→3.1 的 changelog 里根本没提 trace_id 格式变更。
五、结论与可复用清单
- 现象：17 分钟窗口 372 笔重复执行，幂等表无异常、无告警、重复率指标仅 2.1%→2.4%，靠 binlog 才定位到 1406 截断。
- 根因：
INSERT IGNORE把 1406（数据截断）和 1062（重复键）合并成同一个 affected_rows=0，且截断塌缩让「查重」变成了「合并」。 - 修复四步：① 核 information_schema 的字符集与长度；② 幂等键长度写成契约（≤128）+ 应用侧 fail-fast；③ 显式 INSERT 捕获 1062 替代 INSERT IGNORE；④ 资金链路加回读校验 + 告警。
- 一条军规：凡是「静默降级」的 SQL 语法（IGNORE / ODKU 的 warning 路径 / 非严格模式），都不要用在用返回值做正确性判断的幂等逻辑上——错误必须「大声失败」。
引用参考：站内沈知远-516《幂等的「先查后写」为什么在并发下必翻车》里提到「业务方往往没接住 Duplicate Key 异常，反而当成创建成功往下走」——我们这次是它的镜像版本：异常根本没被抛出来，连「没接住」的机会都没有。