网站 A 和网站 B 都出现订单号 100000123，客服认为“订单重复”。Magento 的 entity_id 是全局数据库主键，increment_id 是业务展示编号，Sales Sequence 通常按 Store 生成；不同 Store 出现相同数字可能符合默认设计。

先确认是否真冲突

SELECT entity_id, increment_id, store_id, created_at
FROM sales_order
WHERE increment_id = '100000123';

同一 store_id 出现重复通常会受唯一约束阻止，需要查导入/直接 SQL；不同 store_id 相同则先核对业务要求。外部 ERP 若只用 increment_id 做唯一键，集成设计已经丢失 store 维度。

查看 Sequence 映射

sales_sequence_meta/profile 将实体类型与 Store 的序列表、前缀、后缀和步长关联。不要在生产直接 UPDATE 当前值或复制 sequence 表；并发下可能再次碰撞，下一次升级也难以审计。

前缀比强行共享序列更清晰

业务只需肉眼区分网站时，可为不同 Store 配置稳定前缀，例如 CN-/US-，并确保支付、邮件、发票和 ERP 字段支持字符。若必须全局连续，要设计单一原子序列、容量、回滚和多节点并发，而不是把多个 Store 指向同一旧表后祈祷。

迁移与历史订单

更改规则通常只影响新订单。不要批量重编号已发送给客户或支付平台的历史订单；可以在集成层使用 entity_id/store_id 或独立全局键。任何重编号都涉及发票、退款、物流和审计引用。

修复后并发创建多 Store 订单，验证唯一约束、前缀、邮件、支付回调与 ERP 幂等。订单号可读性不能牺牲交易唯一性。

Invoice、Shipment 也有独立序列

订单号修好不代表发票/发货编号满足外部要求。不同实体有各自 meta/profile 与序列表，前缀策略要整体设计。财务系统若要求发票号法定连续，不能用订单序列配置替代合规方案。

Sequence 空洞不是重复

事务回滚、预取或失败下单可能让编号跳号。为消除空洞而手工回退当前值，会与并发请求碰撞并制造真正重复。先区分“缺号”“跨 Store 同号”“同 Store 重复”三种现象。

监控接近容量上限

序列表自增字段与格式长度应有足够容量。前缀、start_value、step 调整前在预发布生成样本，检查支付平台、物流和客服搜索是否接受。上线后监控唯一约束错误和序列增长，不要等溢出才处理。

API 与人工搜索要使用复合键

集成接口应传 store_id/website code 与 increment_id，或直接使用不可变全局 ID。客服后台也应显示网站标识，避免处理错订单。支付回调若只有 merchant reference，需要在生成时保证该商户账号范围内唯一，并保存与 Magento 实体的映射。

唯一约束要与业务范围一致

数据库约束通常保护 store_id 与 increment_id 的组合，外部系统若要求全局唯一，应在其映射表增加明确约束与冲突告警。不要只在界面校验，因为 API、导入和并发请求都可能绕过。迁移前先扫描历史冲突并制定保留规则。