SQL幂等写入核心是多次执行结果与一次一致，关键靠唯一约束+INSERT IGNORE或ON DUPLICATE KEY UPDATE；需建唯一索引，应用层配合幂等Key（如Redis校验）确保全局安全。
SQL写入操作的幂等性，核心是“多次执行同一操作，结果与执行一次一致”。关键不在于避免重复，而在于让重复变得安全——系统能自动识别、跳过或覆盖，不引发数据错乱、主键冲突或业务异常。
用唯一约束+INSERT IGNORE或ON DUPLICATE KEY UPDATE
这是最常用、最可靠的数据库层幂等写入方式。前提是表中存在能标识业务唯一性的字段组合（如 order_id、user_id + event_type + event_time 等），并为其建立唯一索引。
- INSERT IGNORE：遇到唯一键冲突时静默跳过，不报错也不插入。适合“只新增、不更新”的场景，比如日志记录、事件快照。
-
ON DUPLICATE KEY UPDATE：冲突时执行指定字段更新，例如
INSERT INTO t (id, status, updated_at) VALUES (123, 'paid', NOW()) ON DUPLICATE KEY UPDATE status = VALUES(status), updated_at = NOW()。适合需最终状态一致的业务，如订单状态机。
用UPSERT语句（PostgreSQL / SQL Server / MySQL 8.0.19+）
标准语法更清晰，语义更明确。以 PostgreSQL 为例：INSERT INTO orders (order_id, amount, status) VALUES ('ORD-001', 99.9, 'created') ON CONFLICT (order_id) DO UPDATE SET status = EXCLUDED.status, updated_at = NOW();
注意点：
• ON CONFLICT 后必须指定唯一约束名或列名；
• EXCLUDED 代表本次试图插入但被拒绝的那行数据；
• 更新逻辑应避免无条件覆盖（如不要覆盖创建时间），优先使用 COALESCE(当前值, EXCLUDED.字段) 或按业务规则判断是否更新。
应用层配合：用业务ID做防重Token或幂等Key
数据库无法解决“请求重发但参数未变”带来的重复问题，需在应用层生成并校验幂等Key。
- 幂等Key通常由客户端生成（如 UUID）或服务端基于关键业务参数（如 user_id + order_no + timestamp + nonce）计算哈希，随请求传入。
- 服务端先查缓存（Redis）确认该 key 是否已处理成功；若存在，直接返回上次结果；若不存在，则加锁执行DB写入，并在成功后将 key 写入缓存（设置合理过期时间，如 24 小时）。
- 注意：缓存写入必须与 DB 写入构成原子操作（可用 Redis + Lua 或 DB 事务兜底），否则可能产生“写DB成功但缓存失败”，导致下次请求误判为未处理。
避免常见陷阱
• 不要依赖时间戳或自增ID做幂等依据——它们不具备业务唯一性，也无法应对并发插入；
• UPDATE 不带 WHERE 条件或条件宽松（如只校验 status != 'success'）不是幂等，可能多次修改同一行造成逻辑错误；
• 软删除场景下，唯一索引需包含 is_deleted 字段，否则已删除记录仍会阻挡新记录插入；
• 分布式环境下，避免用本地内存或单节点缓存做幂等判断，必须用共享存储（如 Redis 或数据库表）。
