何时将数据库表的自增ID改为自动生成唯一标识符？

：为何你会对自增ID感到困惑？

在实际项目中。开发者常常因为以下痛点而犹豫是否继续使用自增ID：

1. 高并发插入导致性能瓶颈：大量并发写入时自增锁会成为热点，影响吞吐量。
2. ID冲突与跨库迁移：当业务需要把数据从一套库迁移到另一套库时自增ID容易出现重复或空洞。
3. 分布式程序的唯一性需求：微服务、分片或多活部署场景下单机自增序列难以保证全局唯一。
4. 审计与安全合规：顺序递增的整数 ID 可能泄露业务增长速度或使用者规模。

何时仍然适合使用自增ID？

1. 单表、单库且业务规模可控

如果表仅在单一数据库中使用。且没有跨库、跨地区的同步需求，自增 ID 是最直接、最省资源的方案。

2. 需要自然排序或数据连续性

自增整数天然保持插入顺序。可用于分页、日志查询等场景，避免额外的排序开销。

3. 关联查询频繁且对外键性能要求高

外键索引基于整数类型的查询和连接效率最高，能够明显提高多表关联查询的响应速度。

4. 开发效率与维护成本考量

使用 AUTO_INCREMENT或 IDENTITY可以让插入语句保持简洁，无需在业务层自行生成唯一标识。