【GUID】MySQL全局唯一ID选型方案解析：从 InnoDB 存储机制到分布式架构的演进

一、核心矛盾：InnoDB 聚簇索引的物理约束

MySQL InnoDB 引擎采用聚簇索引（Clustered Index）组织数据，主键不仅决定逻辑唯一性，更直接决定数据的物理存储顺序。这一底层机制是 ID 选型的根本约束条件。

全局唯一ID设计要考虑的核心三原则：

业务 ID 解决的是怎么找到某条记录，数据库主键解决的是怎么存好某条记录。别因为它们都叫 ID，就塞进同一个字段！“

自增ID给 InnoDB 用，业务编号（例：订单order_no使用Snowflake ID）给业务用。此方案是业内比较成熟且稳妥的“双ID”设计，在绝大多数业务场景下都能兼顾性能与扩展性。本质上是把“数据库存储主键”和“业务唯一标识”这两个职责解耦，但注意跨库不宜使用。

如果系统本身就在做分库分表，那自增ID在跨库场景下会重复，这时候可能需要直接用雪花ID做主键，或者用号段模式（如美团开源的Leaf方案）来生成严格递增的全局ID。