mysql如何保证分布式系统下的幂等性_结合唯一键约束与事务控制-mysql教程-PHP中文网

仅加unique索引不够，因并发插入相同值抛异常时业务可能已部分执行，且异常后需手动查状态判断，易误判；insert...on duplicate key update或select...for update配合事务才能可靠实现幂等。

mysql如何保证分布式系统下的幂等性_结合唯一键约束与事务控制

MySQL 用唯一键约束 + 事务能实现分布式幂等性，但必须配合 INSERT ... ON DUPLICATE KEY UPDATE 或显式 SELECT ... FOR UPDATE，否则仅靠 INSERT + 唯一索引会抛异常、无法控制业务逻辑分支。

为什么只加 UNIQUE 索引还不够

单纯在表上加 UNIQUE 约束（比如对 request_id 字段），在并发插入相同值时确实会触发 DuplicateKeyException，但问题在于：

异常发生时，业务逻辑可能已部分执行（如扣款已发消息、库存已预占），INSERT 失败 ≠ 整个操作回滚
捕获异常后，你得自己查一遍当前状态再决定是返回成功还是重试，容易漏判或误判
Spring 的 @Transactional 默认不会捕获并回滚检查型异常，MySQLIntegrityConstraintViolationException 是运行时异常，虽会触发回滚，但无法优雅返回“已处理”语义

`INSERT ... ON DUPLICATE KEY UPDATE` 是最简可行方案

适用于“插入即幂等”，且业务允许用更新覆盖的场景（如写日志、存快照、刷新 token）：

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

必须确保冲突字段有 UNIQUE 或 PRIMARY KEY 约束
UPDATE 子句里不能写计算逻辑（如 counter = counter + 1），否则重复请求会叠加而非幂等
若需区分“首次插入”和“重复忽略”，可在 UPDATE 中设标记字段，例如：updated_at = NOW(), is_repeated = 1

示例：

INSERT INTO idempotent_log (request_id, payload, created_at) 
VALUES ('abc-123', '{"amount":100}', NOW()) 
ON DUPLICATE KEY UPDATE is_repeated = 1, updated_at = NOW();

`SELECT ... FOR UPDATE` 配合事务更可控

适合需要复杂校验、状态流转或带副作用的业务（如支付、下单），但要求：

SELECT 必须走主键或唯一索引，否则升级为表锁，性能雪崩
整个流程必须包在同一个数据库事务中（@Transactional），且隔离级别至少是 REPEATABLE READ
不能先 SELECT 再开事务，否则锁不生效；也不能在事务外查完再进事务，会丢锁

典型流程：

BEGIN;
SELECT * FROM idempotent_record WHERE request_id = 'abc-123' FOR UPDATE;
-- 若查到，直接 COMMIT 并返回 success；
-- 若没查到，INSERT 一条，并继续执行业务逻辑；
COMMIT;

防重表设计与常见踩坑点

单独建一张 idempotent_record 表比在业务表加字段更正交，但要注意：

表结构至少含：request_id（VARCHAR(64) 或 BINARY(16)）、status（TINYINT，如 0=processing, 1=success, 2=failed）、created_at、updated_at
request_id 必须建 UNIQUE 索引，否则 FOR UPDATE 无法精准锁定行
别忘了加过期机制：长期堆积的记录会拖慢查询，建议加 expire_at 字段 + 定时清理任务
不要用 SELECT COUNT(*) 判断是否存在——它不加锁，高并发下必然穿透