SQL幂等写入指多次执行结果与一次执行一致，核心是避免重复数据、保证状态最终一致；其天然不幂等因INSERT/UPDATE/DELETE无约束时会导致重复记录、数值错乱或误删；主流方案包括唯一索引+INSERT IGNORE、条件精确的WHERE更新、UPSERT语句及业务层+数据库双校验。
SQL 幂等写入不是“只执行一次”，而是“多次执行结果与一次执行一致”。核心在于避免重复数据、保证状态最终一致，尤其在分布式、重试、补偿等场景下至关重要。
为什么 SQL 写入天然不幂等？
普通 INSERT、UPDATE、DELETE 在无约束或逻辑控制时，重复执行会引发问题：
- INSERT 不带唯一约束 → 产生多条重复记录
- UPDATE 无条件 or 条件宽松 → 多次更新导致数值错乱（如 status = 'processed' 反复设值没问题，但 balance = balance + 100 就会翻倍）
- DELETE 无精准条件 → 误删或重复删无影响但语义异常
四种主流幂等写入设计方式
1. 唯一索引 + INSERT IGNORE / ON DUPLICATE KEY UPDATE（MySQL）
适用于“有业务唯一标识”的场景（如 order_no、trace_id、user_id+event_type）。
- 建表时加 UNIQUE KEY (order_no)
- 写入用 INSERT IGNORE —— 冲突则静默跳过
- 或用 INSERT ... ON DUPLICATE KEY UPDATE status=VALUES(status), updated_at=NOW() —— 冲突时更新而非报错
2. WHERE 条件精确控制的 UPDATE/DELETE
确保操作仅影响目标状态，重复执行不改变结果。
- UPDATE t SET status='done' WHERE id=123 AND status != 'done'
- DELETE FROM t WHERE id=456 AND status = 'cancelled'
- 关键：条件中包含“当前应满足的状态”，避免无条件更新
3. UPSERT（MERGE）语句（PostgreSQL / SQL Server / Oracle）
标准语法更清晰，显式区分“存在则更新”和“不存在则插入”。
- PostgreSQL：
INSERT INTO t (...) VALUES (...) ON CONFLICT (order_no) DO UPDATE SET ... - SQL Server：
MERGE INTO t USING ... WHEN MATCHED THEN UPDATE ... WHEN NOT MATCHED THEN INSERT ...
4. 业务层 + 数据库双校验（防漏网之鱼）
适合高一致性要求场景，如金融类事务。
- 先 SELECT 检查是否已存在（需配合 FOR UPDATE 或乐观锁防止并发竞争）
- 再 INSERT/UPDATE，并捕获唯一键冲突异常做降级处理
- 注意：SELECT + INSERT 有竞态风险，必须加锁或改用 INSERT ... ON CONFLICT
实战避坑要点
• 主键 ≠ 幂等依据：自增主键无法防止业务重复，必须依赖业务唯一键（如外部订单号）。
• 时间戳不能当幂等条件：NOW() 或系统时间易重复，且无法保证顺序；应使用客户端传入的 trace_id、req_id 等全局唯一请求标识。
• 批量操作要逐条幂等：不要对一批数据整体加锁或统一判断，应按单条记录粒度设计（如 foreach record: upsert on record.id）。
• 日志表也要幂等：操作日志、审计表常被忽略，但重复记录会影响下游统计，同样需要唯一索引或去重逻辑。
面试加分回答建议
被问到“如何设计一个幂等充值接口的数据库写入”，可这样组织答案：
- 接收请求时提取 business_id（如 recharge_id）作为幂等键
- 充值表建 UNIQUE KEY (recharge_id)
- 执行 INSERT ... ON DUPLICATE KEY UPDATE status=VALUES(status), amount=VALUES(amount)
- 同时在应用层记录幂等缓存（如 Redis setex recharge_id 30m），拦截超时前的重复请求
- 失败后支持按 recharge_id 查询状态，避免前端重复提交
重点强调：幂等是端到端的设计，数据库只是其中一环，需结合接口层、缓存、消息队列共同保障。
