新键生成的四种策略

创建新对象要分配一个新键，看似简单，实则暗藏不少麻烦，主要有四条路。自动生成域：数据库自身在插入时把某个字段自动递增成新值，最省事，但麻烦在于插入前很难提前知道这个自动生成的键值是多少——如果要插入一份带多条子项的订单，子项需要用到订单的新键作为外键，而这个值往往要等插入真正发生才能拿到，因此涉及关联对象插入的表通常不适合这种方式。数据库计数器：如Oracle的序列，通过独立的Select语句向数据库要下一个序列值，这个查询在独立事务里自动完成，不会锁住其他正在对同一张表做插入的事务，还能一次多要几个键——效果很好，但不是所有数据库都支持，也没有统一标准。GUID：在本机生成、保证跨越所有时空唯一的长串标识（利用网卡地址、纳秒级时间戳、芯片ID等拼出来），完全不用担心冲突，缺点是生成的字符串很长，人工输入/阅读不便，还可能拖累索引性能。自造键值：最朴素的办法是用SQL的max函数扫描全表拿最大键再加一，会给整张表加读锁，插入少还行，一旦和更新混着跑就很麻烦；更好的自造方案是专门的键表——一张记录”名字/下一个可用值”的表，取键时读出、递增、写回，还可以一次多领几个值减少数据库调用；关键窍门是把对键表的访问放进一个独立的短事务里，这样只锁很短的时间，即便订单插入本身回滚了，从键表领到但没用上的键号也无妨（数字资源本就充裕），还顺带解决了”内存对象一创建就想立刻拿到ID”的需求。

结构图：

flowchart TB
  A["新键生成策略"]
  A --> B["自动生成域<br/>最省事，但插入前拿不到值<br/>不适合有关联对象要插入的表"]
  A --> C["数据库计数器(如Oracle序列)<br/>独立事务不阻塞其他插入<br/>无统一标准"]
  A --> D["GUID<br/>跨时空唯一，无冲突<br/>但字符串长，拖累索引/输入"]
  A --> E["自造键表<br/>读-增-写独立短事务<br/>可一次领多个减少调用"]