本文针对并发批量订单录入时产生的重复订单号问题，提出了一种基于数据库自增主键（orderuid）的解决方案。通过优化表结构，将订单号前缀与orderuid结合，实现订单号的唯一性与并发安全性，并提供了sql视图示例，确保在多系统同时请求下订单号的准确生成。此方法有效避免了传统序列生成机制在高并发场景下的竞态条件，显著提升了数据一致性与系统稳定性。
在处理高并发场景下的订单或发票号生成时，确保其唯一性是一个核心挑战。传统的序列生成方法，如查询最新记录并递增，极易在多系统同时发起请求时遭遇竞态条件，导致重复订单号的产生。
传统序列生成机制的局限性
原始的订单生成逻辑通常依赖于以下两种方式：
-
应用层查询最新序列并递增： 在PHP等应用代码中，通过SELECT Right(OrderNumber,6) FROM tOrders ORDER BY tOrders.OrderUID DESC LIMIT 1;获取当前最大订单号的序列部分，然后进行递增并组合成新的订单号。尽管尝试使用数据库事务进行包裹，但在高并发下，多个请求可能同时读取到相同的“最新”序列号，导致它们生成相同的下一个订单号。随后的OrderExists检查和更新操作，虽然能在一定程度上缓解问题，但增加了逻辑复杂性，且无法从根本上避免初始插入时重复的风险。
foreach($Orders as $order) { $this->db->trans_begin(); $insArr = [ 'OrderNumber' => $this->GenerateOrderNo(), // 可能存在竞态条件 'CreatedBy' => 1, ]; $this->db->insert('tOrder',$insArr); $insert_id = $this->db->insert_id(); if ($this->db->trans_status() === false) { $this->db->trans_rollback(); } else { $this->db->trans_commit(); // 后续检查和更新是一种弥补措施，而非根本解决方案 if($this->OrderExists($insArr['OrderNumber'])) { $insArr = [ 'OrderNumber' => $this->GenerateOrderNo(), // 重新生成，但仍有风险 ]; $this->db->where('OrderUID',$insert_id); $this->db->update('tOrder',$insArr); } } } -
数据库触发器生成序列： 在MySQL中，使用BEFORE INSERT触发器尝试生成订单号。触发器内部同样通过SELECT Right(OrderNumber,6) ... LIMIT 1获取最新序列。这种方式虽然将逻辑下沉到数据库层，但本质上仍是基于查询的序列生成，同样面临竞态条件。在并发事务中，两个并发的INSERT操作可能在触发器中读取到相同的@LastOrderNo，从而生成相同的@NewSequenceNo。
CREATE TRIGGER `Insert_OrderNumber` BEFORE INSERT ON `tOrders` FOR EACH ROW BEGIN SELECT Right(OrderNumber,6) INTO @LastOrderNo FROM tOrders ORDER BY tOrders.OrderUID DESC LIMIT 1; SELECT LPAD(@LastOrderNo + 1, 6,0) INTO @NewSequenceNo; SET NEW.OrderNumber = @NewSequenceNo; END;当为OrderNumber列添加唯一索引时，上述问题会立即暴露，因为数据库会拒绝插入重复值，导致订单录入失败。这进一步证实了基于查询的序列生成在高并发下的不可靠性。
优化方案：利用数据库自增主键保证唯一性
解决并发订单号重复问题的核心在于利用数据库自身提供的原子性与唯一性保证。MySQL的AUTO_INCREMENT主键天然具备这些特性。我们可以将订单号拆分为一个固定前缀和一个基于OrderUID生成的序列号。
1. 优化表结构
修改tOrder表，移除OrderNumber列，转而存储OrderPrefix。OrderUID作为自增主键，将自然地提供唯一的序列部分。
CREATE TABLE `tOrder` ( `OrderUID` INT UNSIGNED NOT NULL AUTO_INCREMENT, `OrderPrefix` CHAR(6) NOT NULL, -- 存储订单号的前缀部分，例如 'ULEN21' `CreatedBy` INT UNSIGNED NOT NULL, `CreatedOn` DATETIME NOT NULL, PRIMARY KEY (`OrderUID`) );
在插入订单时，只需提供OrderPrefix、CreatedBy和CreatedOn等信息，OrderUID将由数据库自动生成并保证唯一性。
2. 动态构建完整的订单号
在查询时，根据OrderPrefix和OrderUID动态组合出完整的OrderNumber。LPAD函数用于将OrderUID格式化为固定长度的序列号（例如6位，不足补零）。
SELECT
OrderUID,
CONCAT(OrderPrefix, LPAD(OrderUID, 6, '0')) AS OrderNumber,
CreatedBy,
CreatedOn
FROM tOrder;例如，如果OrderPrefix是UABC21，OrderUID是1，则OrderNumber将是UABC21000001。如果OrderUID是123，则OrderNumber将是UABC21000123。
3. 使用视图简化查询
为了方便应用层查询，可以将上述组合逻辑封装成一个数据库视图。这样，应用层可以直接查询视图，而无需每次手动拼接订单号。
CREATE VIEW `vw_orders` AS
SELECT
OrderUID,
CONCAT(OrderPrefix, LPAD(OrderUID, 6, '0')) AS OrderNumber,
CreatedBy,
CreatedOn
FROM tOrder;现在，应用层只需简单地SELECT * FROM vw_orders;即可获取包含完整OrderNumber的订单数据。
方案优势与注意事项
- 并发安全性： OrderUID由数据库自动生成并保证唯一性，完全规避了高并发下传统序列生成可能导致的竞态条件。
- 数据一致性： 订单号的序列部分直接来源于主键，确保了其逻辑上的连续性和唯一性。
- 简化应用逻辑： 应用程序不再需要复杂的序列生成和冲突检测逻辑，只需关注业务数据的插入。
- 存储效率： 避免了在OrderNumber列中存储重复的前缀和序列信息，减少了数据冗余。
- 灵活性： OrderPrefix可以根据业务需求进行设计，例如可以关联到特定的业务类型或年份。如果需要更复杂的订单号前缀管理，OrderPrefix甚至可以设计为外键，指向一个独立的OrderPrefixes配置表。
注意事项：
- 此方案依赖于OrderUID的递增性。如果OrderUID由于删除和重新插入等操作导致不连续，那么生成的订单号序列也会不连续，但这通常不影响其唯一性。
- LPAD函数的第二个参数（本例中的6）决定了序列号的长度。请根据预期的订单量和最大OrderUID值合理设置，以避免溢出或截断。
- 如果订单号的生成规则非常复杂，例如需要跨多个表或根据更复杂的业务逻辑生成，可能需要结合数据库序列（如PostgreSQL或Oracle的SEQUENCE）或分布式ID生成器。但对于简单的递增序列，利用自增主键是最简洁高效的方案。
总结
在高并发环境下，生成唯一且连续的业务编号（如订单号、发票号）是常见的挑战。通过将订单号的序列部分与数据库的自增主键OrderUID绑定，并采用动态组合的方式，我们可以构建一个既简单又健壮的解决方案。这种方法不仅保证了订单号的唯一性和并发安全性，还简化了系统设计，提升了数据完整性。
