全局唯一id方案包括：1. 数据库集群id服务，通过专用表生成id并缓存，简单但有单点风险；2. snowflake算法，64位结构支持高并发、趋势递增，依赖机器id分配；3. uuid，无需中心化但无序且占用空间大；4. redis利用incr命令高效生成id，需保障其高可用；5. 数据库号段模式，本地缓存号段减少db压力，如美团leaf-segment。snowflake和号段模式最常用。
在MySQL分布式系统中，生成全局唯一ID是一个常见且关键的问题。传统自增主键在单机环境下表现良好，但在分库分表、多节点写入的场景下容易产生冲突。因此，需要引入能保证全局唯一、趋势递增、高性能的ID生成方案。
1. 基于数据库集群的全局ID服务
通过独立部署一个专用的MySQL实例来生成全局ID，避免与业务数据耦合。
实现方式：- 创建一张专门用于生成ID的表，例如：
id_generator(table_name, last_id, step) - 每次获取ID时，执行
UPDATE id_generator SET last_id = last_id + step WHERE table_name='user'，然后读取新的last_id - 应用层缓存一批ID（如每次取1000个），减少数据库压力
优点是简单可靠，缺点是存在单点风险，需配合主从+高可用方案。
2. Snowflake 算法（雪花算法）
Snowflake 是 Twitter 开源的分布式ID生成算法，生成64位的唯一ID，结构如下：
组成结构：- 1位符号位（固定为0）
- 41位时间戳（毫秒级，可支持约69年）
- 10位机器ID（支持最多1024个节点）
- 12位序列号（每毫秒可生成4096个ID）
优点：全局唯一、趋势递增、不依赖数据库、性能高。可通过ZooKeeper或配置中心分配机器ID，避免冲突。Java中常用开源实现有美团的Leaf、百度的UidGenerator等。
3. UUID
直接使用UUID作为主键，标准格式为32位十六进制字符串（带-共36字符）。
- UUIDv1：基于时间+MAC地址，可能泄露物理位置
- UUIDv4：随机生成，重复概率极低但无序
优点是简单、无需中心化服务；缺点是长度大、无序导致B+树索引效率下降，不适合做主键。若使用，建议用BINARY(16)存储MD5哈希值以节省空间。
4. Redis 生成ID
利用Redis的原子操作INCR或INCRBY生成全局递增ID。
-
INCR global_user_id每次返回唯一递增值 - 可结合Hash Tag实现分段预加载，提升性能
优点是性能好、实现简单；缺点是依赖Redis，需保证其高可用，且重启后不能丢失数据（需持久化配置）。
5. 数据库号段模式（Segment）
结合数据库与本地缓存，减少频繁访问数据库。
工作流程：- 从数据库获取一个号段，如 [10000, 20000)
- 服务本地缓存该区间，逐个分配ID
- 快用完时异步申请下一个号段
代表实现是美团的Leaf-segment，支持双缓冲机制，几乎无停顿。适合高并发场景，兼顾性能与可靠性。
基本上就这些主流方案。选择时需根据系统规模、是否分库分表、对有序性的要求以及运维能力综合判断。Snowflake 和号段模式在生产环境使用最广。
