数据库自增 ID 能做分布式 ID 吗？有什么问题？
简化版
数据库自增 ID 可以在单库单表场景中作为 ID，简单可靠、趋势递增、对索引友好。但在分布式场景中，如果所有服务都依赖同一个数据库生成 ID，会产生单点和性能瓶颈；如果多个库各自自增，又容易 ID 冲突。可以通过设置不同步长、号段模式或独立 ID 表缓解，但高并发、大规模场景通常更推荐号段、Snowflake 或专门 ID 服务。
详细版
数据库自增的优点是实现简单，数据库天然保证唯一和递增，对 MySQL 聚簇索引友好。小系统直接用自增主键非常合理。
问题出现在分布式扩展后。第一，单点问题：所有实例都访问一个库拿 ID，这个库挂了业务写入受影响。第二，性能瓶颈：ID 生成依赖数据库写入或锁竞争，高并发下撑不住。第三，分库冲突：多个库都从 1 开始自增会生成重复 ID。第四，扩容困难：分库分表后 ID 与库表路由、全局排序、数据迁移都变复杂。
常见改进有每个库设置不同初始值和步长，或者用数据库号段一次批量分配一段 ID。号段模式比每次访问数据库自增更适合高并发。
完整版教学
一、数据库自增 ID 的适用范围
数据库自增 ID 是最经典的主键方案。单库单表里，auto_increment 能保证唯一，生成简单，趋势递增，对数据库索引友好。对中小系统来说，它是很好的默认选择，不需要为了“分布式”过度设计。
但问题在于系统规模变化。应用多实例不是问题，因为它们都写同一个表，数据库仍能保证自增唯一；真正的问题是分库分表、多中心部署、ID 生成 QPS 很高，或者多个业务系统需要共享全局 ID。
二、单点和性能瓶颈
如果用一张数据库表专门生成 ID，每次创建业务对象都要插入或更新这张表，那么 ID 生成就变成中心化服务。数据库一旦不可用，所有依赖 ID 的写请求都可能失败。即使数据库可用，高并发下这张 ID 表也可能成为热点。
自增本身还涉及数据库内部维护计数器和并发控制。虽然数据库优化得很好，但把所有业务的 ID 都压到一个点上，并不适合大规模分布式系统。尤其是订单、消息、日志这类高频写入场景，ID 生成应该尽量低延迟和高可用。
三、分库后为什么会冲突
如果有两个库，每个库里的订单表都用自增 ID，从 1 开始递增，那么库 A 会有订单 1，库 B 也会有订单 1。只在单库内部看是唯一的，但全局不唯一。业务一旦需要聚合查询、消息流转、日志排查，就会遇到冲突。
一种简单改法是设置不同初始值和步长。比如两个库时，库 A 生成奇数 ID，库 B 生成偶数 ID；或者 10 个库时步长为 10，每个库使用不同余数。这能避免冲突，但扩容麻烦。库数量变化后，步长和余数设计会变复杂，历史数据也不容易调整。
四、数据库号段模式
号段模式是数据库自增思路的工程改进。不是每次生成 ID 都访问数据库，而是应用一次从数据库申请一段范围，比如 100000 到 199999。之后应用在内存中递增发号，号段用完再申请下一段。
这样数据库访问频率大幅降低，性能比单次自增好很多。为了高可用，还可以双 buffer 预加载下一段号段，避免号段用完时等待数据库。Leaf segment 就是这类思想的典型实现。
五、趋势递增的优势
数据库自增 ID 的一个大优点是趋势递增。对于 MySQL InnoDB，递增主键写入通常是追加写，B+Tree 页分裂少，缓存命中好。相比随机 UUID，自增 ID 在写入性能和索引空间上更有优势。
这也是很多系统即使用了分布式 ID，也仍然偏好生成 bigint 型、趋势递增的 ID，而不是完全随机字符串。分布式 ID 不只是唯一性问题，还要服务数据库存储效率。
六、适合和不适合的场景
数据库自增适合单体、单库、低到中等并发、没有全局跨库 ID 需求的系统。它简单、可靠、维护成本低。不适合高并发全局发号、多机房、分库分表后全局唯一要求强的系统。
如果业务刚起步，直接用数据库自增并不丢人；如果已经分库分表，应该考虑 Snowflake、号段模式、Redis ID 或专门 ID 服务。架构要匹配规模，而不是一开始就追求复杂。
七、面试追问与边界
面试官可能问“数据库自增是不是一定不能用于分布式”。答案不是。可以通过步长、号段、独立发号库等方式使用，只是要承担扩展和可用性成本。另一个追问是“自增 ID 暴露给用户有什么问题”。连续自增容易被猜测业务量、枚举资源，所以对外单号通常需要脱敏或另生成业务号。
还要注意数据库自增在不同数据库和不同配置下细节不完全一样，比如 MySQL 自增锁模式、事务回滚后 ID 是否回退、主从切换后自增值是否一致等。业务不要依赖 ID 连续，只应依赖唯一和大致递增。
还有一个常见工程边界是“ID 是否要求连续”。数据库自增在插入失败、事务回滚、批量申请、数据库重启后都可能出现空洞，所以业务不能依赖 ID 连续。审计、对账、发票流水如果要求连续编号，通常要用专门的业务流水规则和严格状态管理，不能简单拿数据库主键充当连续编号。
八、常见误区与追问
这道题不能只背概念，要把「数据库自增 ID」放回真实分布式系统里解释：参与方是谁、状态怎么流转、失败后怎么恢复，以及它在一致性、性能、可用性之间做了什么取舍。
| 回答层次 | 要讲清的内容 | 容易漏掉的边界 |
|---|---|---|
| 核心结论 | 数据库自增 ID 简单递增、索引友好，但中心化数据库会成为瓶颈，分库分表下全局唯一困难 | 不要停在名词解释 |
| 流程机制 | 应用插入数据库 -> 数据库分配自增值 -> 返回主键 -> 业务使用 ID -> 分库后需设置步长或独立号段 | 说明触发方、存储方、确认点和兜底 |
| 工程取舍 | 单库自增每秒能撑一定写入，但 100 个分库各自从 1 开始会产生重复 ID | ID 方案没有全能答案，要在唯一性、性能、可读性、索引友好和运维复杂度之间取舍 |
数据库自增 ID 面试拆解：
1. 应用插入数据库
2. 数据库分配自增值
3. 返回主键
4. 业务使用 ID
5. 分库后需设置步长或独立号段记忆钩子：先说明唯一性、趋势递增、吞吐、可用性和时钟依赖，再按方案取舍；回答时要紧扣「数据库自增 ID」这道题，不要把相邻概念混成一段泛泛的分布式套话。
- 误区：数据库自增天然分布式唯一。 只在单库单表内唯一，分库分表后会冲突。
- 误区：自增 ID 没有性能瓶颈。 高并发写入会集中到数据库主键生成和单点写入。
- 误区：自增连续就是必须要求。 分布式系统通常只要求趋势递增，不要求严格连续。
- 追问：自增 ID 优点是什么？ 简单、短、趋势递增、索引友好。
- 追问：分库如何避免冲突？ 设置不同起点步长、号段服务或独立 ID 生成器。
- 追问：为什么可能泄露业务量？ 连续 ID 容易被猜测订单规模和增长速度。
九、加强记忆
数据库自增 ID 简单、唯一、递增、索引友好，适合单库单表。分布式场景的问题是单点、瓶颈、分库冲突和扩容困难。改进方式有不同步长、独立 ID 表、号段模式。不要迷信也不要否定：小系统用它很合理，大规模全局 ID 要换更合适的方案。