PostgreSQL中生成易读唯一订单编号：现有方案是否最优？

当前方案的不足 #

你的方案不是最优解，存在几个关键问题：

• 并发冲突风险：查询订单号是否存在与插入新订单是两个独立操作，高并发场景下可能出现两个请求生成相同编号，查询时都显示不存在，最终插入时触发唯一约束报错。
• 编号长度不可控：随着订单量增长，6位编号的重复概率会逐渐升高，导致频繁生成更长的编号，最终订单号长度不一致，既不利于用户识别，也增加系统处理的复杂度。
• 数据库查询开销高：每次生成都要先查询数据库，递归重试会进一步增加数据库请求量，高并发下会放大性能问题。

更优替代方案 #

方案一：原子插入+冲突重试（固定长度易读编号） #

利用PostgreSQL的ON CONFLICT语法，将「生成编号-检查存在-插入」的流程改为原子操作，彻底避免并发冲突，同时保持编号长度固定。

代码示例：

const generateOrderNumber = async() => {
  // 生成固定6位的易读随机字符串
  const number = generateKey(6).toUpperCase();
  try {
    // 尝试插入，冲突时不做任何操作
    await pg.query(`INSERT INTO orders (number) VALUES ($1) ON CONFLICT DO NOTHING`, [number]);
    // 验证是否插入成功（因为DO NOTHING不会抛出错误）
    const checkResult = await pg.query(`SELECT id FROM orders WHERE number = $1`, [number]);
    if (checkResult.rows.length > 0) {
      return number;
    }
  } catch (err) {
    // 处理数据库连接等非冲突类错误
    throw err;
  }
  // 编号重复则递归重试，保持长度不变
  return await generateOrderNumber();
};

// 使用方式
const number = await generateOrderNumber();

优势：保证编号长度统一，原子操作彻底解决并发问题，依赖数据库唯一约束做冲突校验，逻辑更可靠。

方案二：结构化编号（兼顾易读性与唯一性） #

设计包含业务信息的结构化编号，比如「前缀+日期+自增序列+短随机后缀」，既保证全局唯一，又让编号具备可读性（用户能通过编号快速了解订单日期、顺序）。

步骤1：创建PostgreSQL自增序列

CREATE SEQUENCE order_number_seq START 1;

步骤2：生成结构化订单号的代码

const generateOrderNumber = async() => {
  // 生成日期部分（如20240520）
  const dateStr = new Date().toISOString().slice(0, 10).replace(/-/g, '');
  // 获取自增序列值，补零到4位保证长度一致
  const seqResult = await pg.query(`SELECT nextval('order_number_seq') AS seq`);
  const seq = seqResult.rows[0].seq.toString().padStart(4, '0');
  // 生成2位随机易读后缀
  const randomSuffix = generateKey(2).toUpperCase();
  // 拼接成最终编号，比如 ORD20240520-0001-XY
  return `ORD${dateStr}-${seq}-${randomSuffix}`;
};

// 使用方式
const number = await generateOrderNumber();
await pg.query(`INSERT INTO orders (number) VALUES ($1)`, [number]);

优势：完全避免重复，无需重试或额外查询，编号包含业务信息更易读，长度固定便于系统处理。

总结 #

如果需要纯随机、固定长度的易读编号，优先选择方案一；如果希望编号带有业务含义（如订单日期），推荐方案二，这两种方案都比你当前的递归查询方案更可靠、性能更优。

内容的提问来源于stack exchange，提问作者Roger