幂等性保障核心是使重复操作不改变最终结果：插入用唯一索引+IGNORE/ON CONFLICT；更新需带前置状态条件；删除应静默成功；复杂操作须结合唯一标识、状态机与事务控制。

SQL重复执行导致数据异常，核心在于缺乏幂等性保障。关键不是阻止重复，而是让重复操作不改变最终结果。

插入场景：用唯一约束+忽略策略防重复

插入时最常见问题是主键或业务唯一键冲突。直接报错不可取，应主动控制行为。

• MySQL用 INSERT IGNORE 或 ON DUPLICATE KEY UPDATE，后者可做轻量更新（如更新时间戳）
• PostgreSQL用 INSERT ... ON CONFLICT DO NOTHING 或 DO UPDATE
• 务必在业务字段（如订单号、流水号）上建唯一索引，这是幂等的物理基础

更新场景：带条件更新，避免无脑覆盖

UPDATE不能只写 SET status = 'done'，要加上业务状态前置判断。

MySQL8 CRM Schema Design Expert

面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。

下载

• 例如：UPDATE order SET status = 'shipped' WHERE id = 123 AND status = 'paid'
• 返回影响行数，为0说明已被处理，可直接返回成功，不抛错
• 避免用“先查再更新”，防止并发查到旧状态后被其他事务改掉（查-改非原子）

删除场景：允许重复删，但不报错

删除本质是“确保目标不存在”，重复执行本就该静默成功。

• 用 DELETE WHERE ... 即可，无需提前SELECT校验
• 若需确认是否真删了数据，可查影响行数，但不影响业务逻辑走向
• 慎用TRUNCATE，它不支持WHERE，也不具备幂等语义

复杂操作：拆解+状态机+唯一标识

跨表、含计算、分步执行的逻辑，靠单条SQL难保证幂等，需设计状态与上下文。

• 每笔业务操作绑定全局唯一ID（如trace_id、biz_id），记录到日志表或状态表
• 执行前先查该ID是否已成功处理，有则跳过；无则插入标记+执行，两步建议用事务包住
• 状态字段按业务流转定义（如 pending → processing → success / failed），只允许向后推进

基本上就这些。幂等不是加锁，也不是靠应用层重试控制，而是把“重复”当作常态，让SQL和逻辑天然容错。