真正防重复插入必须落在数据库层，前端禁用按钮、后端加锁、先查后插均无法抵御并发请求和绕过校验的直接调用；INSERT IGNORE与ON DUPLICATE KEY UPDATE并非自动去重开关，而是唯一键（PRIMARY KEY或UNIQUE索引）冲突触发的响应机制，无索引时二者等同于普通INSERT，无法防重。
真正防重复插入必须落在数据库层，前端禁用按钮、后端加锁、先查后插——这些都扛不住并发请求和绕过校验的直接调用。
为什么 INSERT IGNORE 和 ON DUPLICATE KEY UPDATE 必须配 UNIQUE 索引
这两个语法不是“自动去重开关”，而是冲突响应机制：只有当 INSERT 触发唯一键（PRIMARY KEY 或 UNIQUE 约束）冲突时，才会执行跳过或更新逻辑。没建索引，它们就等同于普通 INSERT，重复数据照进不误。
- 建索引前务必确认业务语义：要防重的是单字段（如
ANr），还是组合字段（如(ANr, Operator)） - MySQL 允许唯一索引列含多个
NULL，若业务要求“空值也唯一”，得用COALESCE(ANr, 'NULL_PLACEHOLDER')建函数索引，或加CHECK约束 - 建完立刻验证：
INSERT INTO t (ANr) VALUES ('test');再执行一次，应报错1062 Duplicate entry，而不是其他错误码
INSERT IGNORE 和 ON DUPLICATE KEY UPDATE 别选错语义
两者都原子执行，但行为完全不同，混用会破坏业务逻辑。
-
INSERT IGNORE：冲突时静默跳过，rowCount()返回 0；适合“存在即合法，不许新增”的场景（如日志归档、状态上报） -
ON DUPLICATE KEY UPDATE：冲突时强制执行UPDATE子句，哪怕写成ANr = ANr，rowCount()也返回 2；适合需要顺带更新时间戳、计数器等字段的幂等写入 -
INSERT IGNORE会吞掉所有约束错误（外键失败、NOT NULL违反），可能掩盖真实问题；而ON DUPLICATE KEY UPDATE只响应唯一键冲突，更精准
没有唯一索引时，用 INSERT ... SELECT + NOT EXISTS 最稳妥
当无法改表结构加 UNIQUE 索引时，INSERT ... SELECT WHERE NOT EXISTS 是唯一能避开竞态条件的标准方案。
- 必须写成相关子查询：
NOT EXISTS (SELECT 1 FROM t WHERE t.ANr = 'xxx')，不能只写NOT EXISTS (SELECT 1 FROM t) - 严禁用
NOT IN：只要子查询结果含任意NULL，整个条件恒为FALSE，导致插入永远失败 - PostgreSQL 要求外层
SELECT必须括号包裹，否则语法报错：INSERT INTO t (...) SELECT (...) WHERE NOT EXISTS (...) - 判断字段（如
ANr）必须有索引，否则每次插入都触发全表扫描，高并发下直接拖垮性能
最容易被忽略的点：单条语句防重 ≠ 全链路幂等
所有上述机制只保证“这一条 INSERT 语句”不重复，但真实业务常需跨表一致（比如插入订单 + 扣库存 + 记流水）。这时单靠数据库语法远远不够，必须配合：
- 完整事务包裹多步操作
- 用全局唯一 ID（如订单号）作主键，让重复请求因主键冲突直接失败
- 必要时引入 Redis 做请求指纹（
SETNX order_id:123），在 DB 写入前完成轻量级去重
