HiLo与自增bigint效率对比及HiLo相关技术疑问

1. 混合使用HiLo与其他ID生成方式的兼容性问题 #

• 核心取决于两种方式的ID范围是否重叠：
  • 如果不用HiLo的客户端采用独立的ID生成逻辑（比如另一套数据库sequence、UUID），只要保证ID全局唯一，就不会出现冲突问题。
  • 如果对方用的是数据库自增主键（如IDENTITY/AUTO_INCREMENT列），且HiLo生成的ID范围和自增列的范围重叠，就会触发主键冲突。解决办法是提前规划ID区间：比如让HiLo生成的ID都大于自增列的最大预期值，或者反过来，确保两者的ID范围完全不交叉。

2. HiLo与数据库自增ID的性能对比 #

并非数据库自增更优，需结合场景判断：

• 高并发/批量插入场景：HiLo性能更优。一次数据库交互就能获取一批ID（拿到Hi值后，客户端可在本地生成Lo个连续ID），大幅减少数据库往返次数；而自增ID每次插入都要和数据库交互（要么提前取ID，要么插入时由数据库生成，本质都是一次数据库操作）。
• 低并发单条插入场景：两者性能差异不明显，但HiLo依然有优势——可以在业务逻辑中提前生成ID，不需要依赖数据库操作，适合需要提前使用ID的场景（比如生成业务事件、关联临时实体）。

3. 并发场景下的范围锁定与未提交操作的影响 #

• 范围锁定问题：不会出现范围锁定。Hi值通过数据库sequence的NEXTVAL获取，这个操作是原子性的，客户端拿到Hi值后，对应的ID范围（如Hi*Lo到(Hi+1)*Lo-1）归该客户端独占，其他客户端会直接获取下一个Hi值，不存在锁范围的情况，不会导致性能下降。
• 未提交操作的影响：如果客户端拿到ID范围后未提交新增操作，这个范围内的ID会被浪费，但不会影响其他客户端。因为其他客户端已经拿到了不同的Hi值，对应的ID范围不重叠，这些闲置的ID不会被重复使用，只会造成ID不连续，不影响数据一致性。

4. DDD中HiLo的使用价值 #

HiLo在DDD中依然有很高的实用价值：

• DDD中根实体的一致性是业务逻辑层面的，而HiLo的核心优势是在实体创建阶段就能生成唯一ID，不需要等到持久化到数据库。
• 这种提前生成ID的能力，能支持很多DDD场景：比如在内存中构建实体间的关联关系、生成包含实体ID的领域事件、避免“先持久化才能获取ID”的耦合问题。
• 根实体的对象引用只需要唯一ID标识，HiLo生成的ID完全满足这个需求，不会影响数据一致性。

内容的提问来源于stack exchange，提问作者Álvaro García