MySQL 幂等写入怎么设计：重复请求只创建一条订单的取舍

支付确认、创建订单、消息消费这类写入接口，最容易出故障的场景不是单次请求失败，而是同一条业务请求被重试后，数据库里多出了两条重复记录。网络超时、用户手滑点两次提交、消息队列至少投递一次的特性，都可能触发这类问题。最稳的防护边界一定要落到数据库约束层面，不能只靠应用内存里存的临时请求去重列表兜底。

接口目标：同一动作重复到达，结果仍然稳定

要先为每一类业务动作定义固定不变的幂等键，既可以是客户端提前生成透传的 request_id，也可以是“用户、业务类型、外部单号”这组能唯一对应单次操作的业务字段。不要把当前时间、随机值或 HTTP 重试次数这类会变动的内容放进键里，不然每次重试都会被当成全新的操作，完全起不到去重效果。

CREATE TABLE payment_request (
  id BIGINT PRIMARY KEY AUTO_INCREMENT,
  request_id VARCHAR(64) NOT NULL,
  order_no VARCHAR(64) NOT NULL,
  status VARCHAR(20) NOT NULL,
  UNIQUE KEY uk_request_id (request_id)
);

这个建好的唯一索引是最终兜底边界：哪怕两个应用实例完全并行收到同一条请求，也只有其中一次插入能成功执行。MySQL 本身的执行逻辑里，主键或 UNIQUE 索引冲突就会触发重复键拦截，搭配 ON DUPLICATE KEY UPDATE 语法时，原有命中行会直接进入更新逻辑。

调用方体验：重复请求要返回什么

如果约定了同一次业务操作的重复请求参数完全一致，最清晰的处理逻辑通常是先尝试插入新记录；碰到重复键冲突后直接读取库中已存在的旧记录，把第一次处理生成的订单号和状态原样返回给调用方。调用方拿到的结果完全稳定，不需要猜测这次请求到底是执行成功还是失败。

若业务允许同一条幂等键触发部分字段更新，再走更新逻辑，但要明确约定哪些字段可以被修改。状态流转节点、金额、收款账户这类核心字段，通常不能在重复请求的分支里被悄无声息地覆盖。

INSERT INTO payment_request (request_id, order_no, status)
VALUES (?, ?, 'PENDING')
ON DUPLICATE KEY UPDATE request_id = request_id;

上面的写法只是把重复键冲突导流到可识别的处理路径，后续仍然要读出已有记录核对所有核心参数。不要直接用SQL的受影响行数判定全链路业务逻辑，也不要把 INSERT IGNORE 当成通用幂等方案：它会把很多本该抛出的异常直接转成静默警告，可能悄悄掩盖底层的数据质量问题。

错误模型：键相同但业务参数不同怎么办

这种情况不属于正常重试，本质是不同请求发生了业务冲突。应该直接返回明确的冲突结果同时落全审计信息，不要复用旧订单，也不要不加校验就把旧记录改成新请求的参数。接口文档要写清幂等键的有效期、重复请求返回格式、哪些字段必须参与一致性校验。

兼容与上线检查

1. 先清理历史重复数据，再建立唯一索引。
2. 灰度观察重复键数量、冲突数量和接口重试率。
3. 为超时重试、并发重复和参数冲突补充回归用例。
4. 保留快速回滚方案，避免索引变更影响写入高峰。

常见问题

只在 Redis 里记请求键可以吗？

缓存可以减少重复逻辑的执行开销，但不能替代数据库的唯一约束。缓存过期、节点故障或是多实例竞争写的场景下，最终一致的写入边界仍然要由数据库保证。

ON DUPLICATE KEY UPDATE 就等于幂等吗？

不等于。它只是SQL层提供的一种分支能力；整套幂等逻辑还需要搭配固定的业务键、参数一致性校验、清晰的返回契约才能跑通。

幂等键要永久保存吗？

按照业务重试窗口、审计要求和存储成本决定保留周期就可以。核心要求是有效期不能短于调用方可能的重试和补偿时间范围。

总结

MySQL幂等写入的核心不是靠某条写法精巧的SQL，而是把稳定业务键生成、唯一索引约束、重复请求返回规则、冲突处理逻辑设计成统一的交互契约。数据库负责拦住第二次重复创建的请求，上层应用只需要把首次执行的结果或者明确的冲突提示返回给调用方即可。