SQL 自增 ID 本质是单机单表的顺序计数器，依赖数据库锁或缓存保证递增不重复；在分布式多实例、分库分表、主从多写等场景下会因各自独立生成而导致 ID 冲突或不唯一。
SQL 数据库的自增 ID（如 MySQL 的 AUTO_INCREMENT、PostgreSQL 的 SERIAL）本质是单机、单表维度的顺序计数器，依赖数据库内部锁或缓存机制保证递增不重复。但在分布式系统中，多个数据库实例或分库分表场景下，这种本地自增机制会直接失效，导致 ID 冲突或全局不唯一。
自增 ID 在单库下的工作原理
以 MySQL 为例：每张含 AUTO_INCREMENT 主键的表维护一个内存中的“当前最大值”，插入新行时加 1 并写入；重启后会通过扫描表中最大 ID 重新初始化该值（InnoDB 在 8.0+ 改为持久化到重做日志，避免重启回退）。整个过程由引擎层加表级或意向锁控制，并发插入仍能保证连续、递增、不重复——但仅限于 ** 同一张表、同一个实例 **。
分布式环境下自增 ID 为何失效
- 多实例独立生成：不同 MySQL 实例各自维护自己的
AUTO_INCREMENT值，比如实例 A 生成 1,2,3，实例 B 也生成 1,2,3，ID 全局重复 - 分库分表后主键非全局唯一：订单库按用户 ID 哈希拆成 4 个库，每个库的 order 表都从 1 开始自增，不同库产生的 order_id=1001 会撞车
- 主从延迟或双写场景下无法协调：主库和从库同时接受写入（如多活架构），自增步长配置不当会导致主从 ID 交叉覆盖
- 迁移 / 合并数据时 ID 重叠：将多个旧库合并到新库，各源库的自增 ID 天然存在大量重合
替代方案：如何生成全局唯一分布式 ID
核心思路是脱离数据库自增，改用应用层或中间件统一发放，常见方案有：
- UUID / UUIDv4：本地生成，无中心依赖，但长度长（32 位十六进制）、无序、索引效率低，不适合高频写入主键
- Twitter Snowflake（及变种如 百度 UidGenerator、 美团Leaf）：64 位整数，含时间戳 + 机器 ID+ 序列号，趋势递增、全局唯一、高性能；需自行部署 ID 服务或集成 SDK
- 数据库号段模式：ID 服务批量向 DB 申请一段可用 ID（如 1–1000），缓存在内存中分发，用完再取；减少 DB 交互，兼顾性能与可靠性
- Redis INCR 原子计数器：利用 Redis 单线程原子性，
INCR生成递增 ID；需注意 Redis 高可用和网络分区影响，适合中小规模系统
实际选型建议
不必强求“完美方案”，应结合业务特点权衡：
