数据库表主键id自增，有哪些潜在风险或弊端？

自增主键 ID：看似便利， 暗藏的风险与思考

在信息化的春天里数据库像一棵参天大树，为我们的业务提供肥沃的土壤。很多开发者在创建表时 第一时间就会给它装上一个自增主键 id仿佛给小苗系上一根向上生长的藤蔓。只是这根藤蔓虽好，却也可能在风雨中摇晃，带来不易察觉的隐患。

1️⃣ 唯一性与“跳号”现象

自增主键天生具备唯一性——唯一性：主键值必须是唯一的，不能重复。但当记录被删除后 AUTO_INCREMENT 并不会回填空缺，而是继续递增，这会导致所谓的“跳号”。如果业务需要连续的编号，这种跳号会让人抓狂，也可能引发审计合规问题，拖进度。。

2️⃣ 合并数据时的冲突危机

想象两家子公司各自使用自增 id接着要进行数据合并。原本互不相干的 id 在同一张表里出现重复——数据合并,两个Id一样怎么办？若没有预先规划，就会出现外键失效、关联错乱等连锁反应，简直了。。

3️⃣ 分布式环境下的 瓶颈

在微服务或分库分表的大潮中，自增主键往往成为“单点”。不同库之间无法保证 id 的全局唯一，导致写入冲突。 泰酷辣！ 于是我们不得不引入雪花算法、UUID 或者业务层生成的唯一标识，以换取更好的横向 能力。

4️⃣ 索引膨胀与查询性能下降

基本上... 虽然自增主键天然是聚簇索引， 但当表的数据量突破千万甚至上亿时索引文件会变得庞大。每次插入都需要把新页追加到磁盘尾部， 这种顺序写虽然快，却容易产生“热点”，导致磁盘 I/O 集中，在高并发场景下可能出现性能瓶颈。

5️⃣ 平安隐患与信息泄露

太扎心了。 连续递增的数字很容易被外部推算出系统规模。比方说 一个公开的 API 返回了用户列表，其中包含了 id；攻击者只要遍历这些数字，就能猜到未授权的数据是否存在。这种信息泄露风险在涉及隐私或金融业务时尤为致命。