如何利用SQL触发器防止重复订单的并发生成：构建唯一性校验逻辑
触发器里不能用 SELECT ... FOR UPDATE
不少开发者会想到一个方案：在 INSERT 触发器里先查询订单号是否存在，然后试图加锁来防止并发插入。但这条路其实走不通。原因在于，MySQL 的 BEFORE INSERT 触发器虽然运行在语句执行之前，但此时事务并未真正持有锁。更关键的是，触发器内部根本不支持 SELECT ... FOR UPDATE 这类锁定读操作，通常会直接报错。退一步说，即使语法上允许，多个并发会话同时进入触发器时，仍然可能都查询到“不存在”的结果，然后相继执行插入，导致重复。
那么，真正可靠的方案是什么？答案是，把唯一性校验的责任下推到存储引擎层：
- 最直接、最高效的方法，就是给订单号字段加上
UNIQUE唯一约束。 - 如果业务上需要返回更友好的错误提示（例如“该订单已存在”，而不是冷冰冰的“Duplicate entry”），可以在唯一约束的基础上，再用触发器来捕获冲突并抛出自定义信息。
- 切记，不要在触发器里手动执行“查询-判断-阻断”这套逻辑。它不仅不可靠，还会严重拖累性能。
BEFORE INSERT 触发器只能做轻量预检
BEFORE INSERT 触发器的定位，其实更适合做一些格式校验、默认值填充或者简单的逻辑拦截。比如，检查订单号是否为空、是否符合特定的正则模式、长度是否超限等等。但它确实无法安全地完成“记录是否存在”这种终极判定。
来看一个典型的例子，只做基础过滤，不触碰唯一性判断：
CREATE TRIGGER check_order_no_format
BEFORE INSERT ON orders
FOR EACH ROW
BEGIN
IF NEW.order_no IS NULL OR LENGTH(NEW.order_no) < 6 THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = '订单号不能为空且至少6位';
END IF;
END;
这里有个细节需要注意：触发器中的 SIGNAL 只能中断当前语句的执行，它并不能替代数据库约束。一旦发生 UNIQUE 约束冲突，这个错误是在触发器执行完毕之后才被抛出的。所以，触发器里的错误提示和引擎层的约束冲突，是两套独立的机制。
唯一约束 + 应用层重试才是生产级解法
说到最后，数据库层面最坚实的防线就是 UNIQUE KEY (order_no)，它能拦住绝大多数并发重复。而应用层则需要负责兜底处理和优化用户体验。这套组合拳，也是 MySQL 官方推荐的并发控制最佳实践。
具体操作上，可以遵循以下几点建议：
- 建表时，务必为订单号字段加上唯一约束，哪怕这个订单号是业务系统生成的（比如“时间戳+随机数”的组合）。
- 应用代码应该捕获
1062这个具体的错误码，而不是去解析可能因语言或版本而变化的错误消息文本。 - 如果需要实现幂等创建，可以考虑使用
INSERT IGNORE或ON DUPLICATE KEY UPDATE，但务必确认其语义是否符合业务逻辑（例如，静默忽略重复是否被允许）。 - 避免在触发器内调用存储过程去进行远程校验（比如查询 Redis 或调用外部 API），网络延迟和失败会极大增加事务的复杂性和风险。
为什么不用 AFTER INSERT + 回滚？
可能还有人会想：能不能在 AFTER INSERT 触发器里检查，发现重复了就执行 ROLLBACK 回滚呢？答案是，MySQL 不允许在触发器内部执行 ROLLBACK 语句。况且，到了 AFTER 阶段，数据已经写入，此时回滚的代价很高，还可能引发主从复制的一致性难题。
对于更复杂的业务校验场景，比如“同一用户5分钟内不能重复下单同一商品”，正确的解决思路应该是：
- 在应用层的事务中，先通过带
FOR UPDATE的SELECT锁定相关的用户行或商品行。 - 或者，引入分布式锁（如 Redis 的 SETNX 命令）配合 TTL 来控制时间窗口。
触发器并不是为这类复杂业务规则设计的。强行把逻辑塞进去，只会让问题变得更加隐蔽和难以维护。
归根结底，对于唯一性校验这个问题，数据库约束本身就是最优雅的答案。其他所有绕路的方案，要么是错误的，要么是低效的，要么会给未来的维护埋下深坑。
