高并发场景下订单号重复问题的解决方案：利用数据库自增ID实现唯一序列

本文探讨在高并发批量插入场景中，如何避免订单号重复。传统基于最后一条记录递增的方式易导致竞态条件。文章提出利用数据库的`auto_increment`主键作为订单序列的核心，结合订单前缀生成完整订单号，并通过视图简化查询，从而确保订单号的唯一性和并发处理的鲁棒性。

高并发批量插入中订单号重复问题的根源

在处理高并发的批量订单插入场景时，一个常见的问题是生成唯一的、递增的订单号。当多个系统或进程同时尝试插入订单，并根据当前数据库中最新订单号进行递增时，极易发生竞态条件，导致订单号重复。

原始的订单表结构和订单号生成逻辑如下：

CREATE Table tOrder
(
   OrderUID Int NOT NULL AutoIncrement,
   OrderNumber  Varchar(12) NOT NULL ,
   CreatedBy Int,
   CreatedOn DateTime,
   Primary Key(OrderUID)
);

订单号格式为 ULEN21000001 或 UCMC21000002，其中后六位是递增的序列号。生成逻辑通常是查询当前表中最大的订单号，提取其后六位并加一。

SELECT Right(OrderNumber,6) FROM tOrders ORDER BY tOrders.OrderUID DESC LIMIT 1;

这种方法在单线程或低并发环境下工作良好，但在高并发场景下，例如当系统A和系统B同时发起批量插入请求时，它们可能会同时查询到相同的“最新”订单号，并基于此生成相同的下一个订单号，从而导致重复。即使尝试通过PHP事务或MySQL触发器来处理，也难以完全避免这种竞态条件，因为获取“下一个序列号”的逻辑本身就存在并发漏洞。

例如，PHP代码中尝试在事务中生成订单号，并在发现重复时进行更新：

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);
    }
  }
}

这种逻辑存在两个问题：

1. GenerateOrderNo() 方法内部如果仍是基于查询最新订单号来递增，那么在并发环境下依然可能生成重复。
2. 即使检测到重复并尝试更新，也意味着先插入了一个可能重复的记录，然后又去更新，增加了数据库操作的复杂性和潜在的死锁风险。

MySQL触发器也面临同样的问题：

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

在BEFORE INSERT触发器中查询tOrders的最新记录来生成新订单号，同样可能在并发插入时获取到相同@LastOrderNo，从而生成重复的@NewSequenceNo。

为OrderNumber列添加唯一索引虽然可以阻止重复数据的插入，但它只会导致插入操作失败并报错，而非解决订单号的生成问题。

解决方案：利用数据库自增主键和视图

解决此问题的核心在于，将订单号的“序列”部分与数据库的唯一自增ID关联起来。数据库的AUTO_INCREMENT主键天然具备唯一性、递增性和并发安全性，是生成序列号的理想选择。

1. 优化表结构

将订单号拆分为两部分存储：

序列猴子开放平台

具有长序列、多模态、单模型、大数据等特点的超大规模语言模型

0

查看详情

• OrderPrefix: 订单号的静态前缀部分（例如 ULEN21 或 UCMC21）。
• OrderUID: 数据库自动生成的唯一主键，作为订单号的动态序列部分。

修改后的表结构如下：

CREATE TABLE `tOrder` (
  `OrderUID` INT UNSIGNED NOT NULL AUTO_INCREMENT,
  `OrderPrefix` CHAR(6) NOT NULL, -- 存储订单前缀，例如 "UABC21"
  `CreatedBy` INT UNSIGNED NOT NULL,
  `CreatedOn` DATETIME NOT NULL,
  PRIMARY KEY (`OrderUID`)
);

此结构不再直接存储完整的OrderNumber，而是将其分解。OrderUID将作为唯一的、自动递增的序列。

2. 生成完整订单号

当需要显示或查询完整的订单号时，可以通过SQL函数CONCAT和LPAD动态生成：

SELECT
    OrderUID,
    CONCAT(OrderPrefix, LPAD(OrderUID, 6, '0')) AS OrderNumber, -- 动态拼接完整的订单号
    CreatedBy,
    CreatedOn
FROM tOrder;

• CONCAT(OrderPrefix, ...)：将订单前缀与序列号拼接。
• LPAD(OrderUID, 6, '0')：将OrderUID转换为字符串，并在左侧用零填充，使其总长度达到6位。例如，如果OrderUID是1，则变为000001；如果是123，则变为000123。

这种方法确保了OrderNumber的唯一性，因为它基于OrderUID这个唯一的自增主键。

3. 使用视图简化查询

为了方便应用程序查询完整的订单号，可以创建一个视图（View）：

CREATE VIEW `vw_orders` AS
SELECT
    OrderUID,
    CONCAT(OrderPrefix, LPAD(OrderUID, 6, '0')) AS OrderNumber,
    CreatedBy,
    CreatedOn
FROM tOrder;

现在，应用程序可以直接从vw_orders视图中查询，就像查询普通表一样，而无需每次都手动拼接订单号：

SELECT OrderNumber, CreatedBy, CreatedOn FROM vw_orders WHERE OrderUID = 123;

4. 应用程序层的插入逻辑

应用程序在插入新订单时，不再需要复杂的订单号生成逻辑。它只需提供OrderPrefix和CreatedBy，让数据库自动处理OrderUID的生成：

// 假设 $orderPrefix 为 "UABC21"
// 假设 $createdBy 为 1
$insArr = [
    'OrderPrefix' => $orderPrefix,
    'CreatedBy'   => $createdBy,
    'CreatedOn'   => date('Y-m-d H:i:s') // 或者使用 CURRENT_TIMESTAMP
];

$this->db->insert('tOrder', $insArr);
$insert_id = $this->db->insert_id(); // 获取新插入的 OrderUID

这种方式极大地简化了应用程序的逻辑，将订单号的唯一性保证完全委托给数据库。

优势与注意事项

优势：

1. 保证唯一性： OrderUID作为AUTO_INCREMENT主键，数据库层级保证了其唯一性，从而间接保证了最终OrderNumber的唯一性。
2. 并发安全： 数据库的AUTO_INCREMENT机制是为高并发设计的，它能高效且安全地生成唯一序列，避免了竞态条件。
3. 简化应用逻辑： 应用程序无需再实现复杂的订单号生成和冲突检测逻辑，只需关注业务数据。
4. 提高性能： 避免了在每次插入前查询最大订单号的开销，减少了锁竞争。
5. 数据完整性： 订单号的生成逻辑集中在数据库层面，更易于维护和确保数据一致性。

注意事项：

• OrderPrefix的设计： OrderPrefix可以根据业务规则（如年份、部门、地区代码等）动态生成。如果OrderPrefix本身也需要唯一性或有特定的管理逻辑，可以将其设计为外键，关联到一个独立的tOrderPrefix配置表。
• OrderUID的长度： LPAD的填充长度（示例中为6）应根据预期的最大订单量来确定，确保OrderUID增长到一定程度后仍能保持所需的位数。
• 非连续性： AUTO_INCREMENT主键在某些情况下（如事务回滚、批量插入失败）可能出现不连续的跳号。如果业务上严格要求订单号必须连续，则需要更复杂的分布式锁或序列服务方案，但对于大多数业务而言，唯一性比严格连续性更重要。

总结

在高并发场景下，避免订单号重复的关键在于利用数据库的AUTO_INCREMENT主键的并发安全性和唯一性。通过将订单号分解为静态前缀和动态自增序列，并在查询时动态拼接，可以构建一个健壮、高效且并发安全的订单号生成机制。这种方法不仅简化了应用程序逻辑，也极大地提高了系统的稳定性和数据完整性。

以上就是高并发场景下订单号重复问题的解决方案：利用数据库自增ID实现唯一序列的详细内容，更多请关注php中文网其它相关文章！