如何避免SQL存储过程重复提交订单？-SQL-PHP中文网

必须先建唯一约束，否则所有防重语法都失效；mysql用insert on duplicate key update最可靠但仅响应主键或唯一键冲突；sql server慎用merge因其严格依赖on条件与索引一致性；触发器仅作兜底且需主动signal中断并确保被查字段有索引。

如何避免sql存储过程重复提交订单？

必须先建唯一约束，否则所有防重语法都失效

存储过程里写再多 MERGE、ON DUPLICATE KEY UPDATE 或 ON CONFLICT，只要目标表没建 UNIQUE INDEX 或 PRIMARY KEY，就等于没设防。MySQL 会退化成普通 INSERT，SQL Server 报错 The MERGE statement attempted to UPDATE or DELETE the same row more than once，PostgreSQL 直接抛出 there is no unique or exclusion constraint。

常见错误是只靠业务逻辑“认为”字段唯一，比如以为 order_no 不会重复，却没执行：

ALTER TABLE orders ADD UNIQUE (order_no);
多字段组合唯一时漏掉括号：正确是 ADD UNIQUE (tenant_id, order_no)，不是 ADD UNIQUE tenant_id, order_no
用 ANr 当唯一标识，但没加索引，导致后续所有防重语句不触发

MySQL 存储过程中优先用 INSERT ON DUPLICATE KEY UPDATE

MySQL 没有 MERGE，INSERT ... ON DUPLICATE KEY UPDATE 是最可靠的选择，但它只响应主键或唯一键冲突，其他约束（如 NOT NULL、外键失败）仍会直接报错，不会进 UPDATE 分支。

批量插入别写循环，用 VALUES ROW(), ROW(), ...；但要注意 max_allowed_packet 限制，超限会报错 Packets larger than max_allowed_packet are not allowed。

如果业务要求“存在则不变”，别写 col = VALUES(col)——这会覆盖原值；真要更新时间戳，只更新无副作用字段：

INSERT INTO orders (order_no, user_id, amount) 
VALUES ('ORD-123', 1001, 99.9)
ON DUPLICATE KEY UPDATE updated_at = NOW();

SQL Server 存储过程慎用 MERGE

MERGE 看似一步到位，实际极易踩坑：它不是“智能去重”，而是严格匹配 ON 条件与唯一索引字段。一旦 ON 子句和索引字段不一致，比如索引是 UNIQUE (tenant_id, order_no)，但写成 ON t.order_no = s.order_no，就会误删或漏更新。

容易被忽略的陷阱：

漏写 WHEN NOT MATCHED BY SOURCE THEN DELETE？旧数据越积越多
源数据嵌套太深，比如 SELECT ... FROM (SELECT ...) s，执行计划不可控，建议先写入 #staging 临时表再 MERGE
UPDATE SET col = ISNULL(s.col, t.col) 是危险写法：当 s.col 为 NULL，会把 t.col 覆盖成 NULL，改用 CASE WHEN s.col IS NOT NULL THEN s.col ELSE t.col END

触发器只是兜底，不是主力

95% 的重复提交问题，靠 UNIQUE (user_id, request_id) 就能拦住。触发器只应在涉及多表状态、时间窗口判断或需调用外部服务时才启用。

在 BEFORE INSERT 触发器里查重，不能只 SELECT COUNT(*) 然后啥也不做——插入照样发生。必须用 SIGNAL SQLSTATE '45000' 主动中断：

SELECT 1 INTO @exists FROM orders WHERE order_no = NEW.order_no;
IF @exists IS NOT NULL THEN
  SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'duplicate submit';
END IF;

最关键的是：被查字段必须有索引，否则每次插入都全表扫描；绝对不要在触发器里写 SELECT ... FOR UPDATE，隐式锁会把高并发堵死。