直接回答：主流方案四族：UUID（无序、128 位，简单但做数据库主键导致页分裂和索引膨胀）；数据库号段模式（每次批量取一段 ID 内存自增，DB 压力小、ID 递增）；Redis 自增；雪花算法——64 位拆成 时间戳(41) + 机器位(10) + 序列号(12)，本地生成、趋势递增、无中心瓶颈，是订单号类场景的主流。选型看排序需求、可读性、存储成本与运维意愿。
展开解析：雪花的坑都集中在机器位和时钟。机器位分配：手工配置易重复（容器环境 IP/实例名动态），重复即 ID 冲突——通常用 ZooKeeper/数据库注册或 K8s StatefulSet 序号解决。时钟回拨：本机时间倒退会导致已用时间戳上的序列号重发，处理策略是检测到回拨后拒绝服务、等待追上或切备用机器位；NTP 大步校准是触发源，生产上 NTP 配 slew 模式微调。趋势递增≠严格递增：同一毫秒内多节点并发生成的 ID 大小关系不保证全局有序，业务别依赖 ID 排序代替创建时间（精确排序用 ID+时间列复合索引）。号段模式容灾简单（段用完前 DB 挂了无感），但 ID 可枚举业务量——对安全性敏感的对外 ID 需加随机段或加密。
追问方向：为什么 UUID 做 InnoDB 主键会页分裂？Leaf/TinyID 这类号段实现怎么做高可用？时钟回拨检测怎么做？
（约 460 字）