MongoDB 全局唯一流水号终极方案：唯一索引 + 应用层重试，事务内 findAndModify 不可靠
事务内使用 findAndModify 无法保证流水号唯一
许多开发者存在一个认知误区，认为在 MongoDB 事务中执行 findAndModify 操作来更新计数器并生成流水号，可以依靠事务的隔离性来避免重复。实际上，这种做法并不可靠。虽然 findAndModify 在事务内部是原子操作，但事务本身无法阻止多个并发事务同时读取到相同的旧计数值，并各自进行递增计算。
设想一个高并发场景：多个事务几乎同时启动，都读取到序列号 00001，然后各自计算出相同的流水号 BTA2026041000002。最终在插入数据时，才会因唯一索引冲突而报错。这并非预防重复，而是在发生碰撞后才进行被动处理。
正确方案：依赖唯一索引约束与客户端重试机制
MongoDB 并未提供传统关系型数据库中的“锁表”机制。其实现全局唯一性的核心在于利用唯一索引来强制约束数据唯一性。可靠的实现路径如下：
- 预先创建唯一索引：在流水号字段（例如
serialNo）上建立唯一索引，命令为：db.orders.createIndex({ serialNo: 1 }, { unique: true })。 - 应用层生成并尝试插入：在业务代码中直接生成候选流水号（例如
BTA2026041000001），然后执行insertOne操作。注意，无需预先查询或占用序号。 - 捕获冲突错误并重试：捕获
11000错误码（重复键错误），这表明该流水号已被使用。此时应立即重试生成下一个序号（如00002）并再次尝试插入。 - 设置合理的重试上限：建议将重试次数限制在 3 到 5 次，超过上限则抛出异常，以避免无限重试循环。
此模式巧妙地将冲突检测交由数据库存储层完成，相比在应用层实现复杂的锁逻辑或依赖事务，更为轻量且稳定。
为何应避免使用事务包裹 update 与 insert 操作？
另一种常见的错误做法是：尝试在一个事务中先 update 计数器文档，再使用新值拼接流水号进行 insert。这种方案存在以下问题：
- 数据状态不一致风险：计数器更新成功，并不保证业务数据的插入也能成功。若中间环节失败，会导致计数器已递增而业务数据未入库，产生“跳号”。
- 并发冲突仍可能发生：即使多个事务对计数器的更新会被 MongoDB 串行化处理，但基于新值生成的流水号，在极高并发下仍可能因时间戳、随机因子等短时相同而发生碰撞。
- 性能瓶颈：事务持有锁的时间越长，系统吞吐量下降越明显。而基于唯一索引的冲突判断是瞬时完成的，几乎没有锁竞争开销。
关键设计细节：索引字段类型与结构
一个至关重要的细节是：流水号字段必须存储为字符串（String）类型，切勿转换为数字。原因如下：
- 支持字母前缀：流水号通常包含字母前缀（如
BTA），数字类型无法处理，会导致数据截断或写入错误。 - 保持格式完整：如
00001这类补零格式，在数字类型中会丢失前导零，查询结果为1，将导致排序和范围查询逻辑混乱。 - 优化查询性能：MongoDB 的字符串索引能高效支持前缀匹配查询，例如索引
{ serialNo: 1 }可优化类似serialNo: { $regex: "^BTA20260410" }的查询条件。
此外，需避免一种错误设计：不要在多个字段组成的复合键（例如 { prefix: "BTA", date: "20260410", seq: 1 }）上建立唯一索引。这仅能保证“同一天同一前缀下”不重复，丧失了流水号的全局唯一性，违背了设计初衷。
实际应用中，真正的挑战往往在于边界条件的重试时序控制。例如，当单日单据量接近序列号上限（如 99999）时，应用层必须加入有效的“日期切换”检测逻辑。否则，在日期切换的瞬间，大量重试请求可能集中爆发，对数据库造成压力。这类边界保障，需要由应用逻辑来完善，MongoDB 无法自动处理。
