运营发现订单号从 1000123 跳到 1000127，第一反应是中间三张订单丢了。另一边，两个网站又出现“相同订单号”。这两种现象必须分开：跳号在并发、回滚和预取场景下可能正常；真正重复则涉及 Store 维度或定制代码。
先用 entity_id、increment_id 和 store_id 对账
SELECT entity_id, increment_id, store_id, created_at, state, status
FROM sales_order
WHERE created_at BETWEEN :from AND :to
ORDER BY entity_id;不要只按 increment_id 搜索。Magento 的订单显示号通常与 Store 关联，不同 Store 可能使用不同 sequence，因此跨网站看到相同数字不一定违反数据库唯一约束。先确认业务要求是“全站唯一”还是“店铺内唯一”。
为什么会跳号
Sequence 号被取得后，后续事务可能失败或回滚，已经消耗的值不会自动回收。并发请求、支付失败、风控拒绝都可能留下空洞。空洞不等于存在被删除订单，更不能据此补造记录。
检查 sales_sequence_meta、sales_sequence_profile 与对应 sequence_order_* 表，核对当前 Store 使用的表、前缀、后缀与步长。只读查看 AUTO_INCREMENT 可以帮助判断下一号，但不要在营业中直接改小。
真正危险的是自定义生成器绕过原子性
有些模块用“查询当前最大值 + 1”生成订单号。在两个并发请求下，两边都可能读到同一个最大值。正确做法应依赖数据库原子序列或带唯一约束的幂等分配，不能靠 PHP 锁或毫秒时间戳碰运气。
迁移数据时也要注意导入的 increment_id 与本地序列。若导入历史订单后没有把序列推进到安全位置，新订单可能撞号；反过来盲目把 AUTO_INCREMENT 调得很大，只会造成更明显的跳号。
处理原则
如果只是合法空洞，向运营解释原因并用支付/quote 日志证明没有丢单，不需要填号。如果发现同一 Store 真正重复，立即停止相关定制生成器，确认数据库约束与受影响订单，并评估财务、发票和 ERP 引用。修复后用并发压测验证序列唯一，失败事务允许留空洞，但绝不能重复。
