数据库自增 id 不连续会有什么问题吗？

@wxf666 #20 这 3 个问题不会出现 也不会出现任何意想不到的问题 除了 id 比预期值要大之外没有什么
如果你的数据量够大主键直接用 bigint
https://dev.mysql.com/doc/refman/5.7/en/innodb-auto-increment-handling.html
可以看官方文档了解下

正常应用没影响，骚应用就不好说了

怎么会没问题呢，业务量不大的话够用当然是 ok 的，业务数据如果多的情况下，回滚导致的空洞会让某个表的可承载数据量减少，例如实现的时候有 bug 或者漏洞，导致大批量的回滚操作，浪费了自增 id 的号段，原本能存放下 18446744073709551615 条数据（数字随便编的，记不准了）现在可能只能放下一半，或者更少的数据了。

简单应用、维护得当可能看不出什么问题，但是稍不注意就会某一天突然报错了，而且是完全意料不到的，因为开发者可能认为比如 1 年内最多也就产生几千万条数据，单表轻轻松松，但是却因为实现上的缺陷导致 id 提前耗光，没加监控或者处理的话这在生产环境就是个 P0 的故障，数据写入不了。

我觉得最重要的是，开发者有没有意识到自增 id 的空洞存在、回滚会浪费多少的 id ，浪费之后的 id 字段类型（ int 、bigint ）是否还够用，评估好的话完全 ok 的，只是怕有些时候是意料之外的空洞。

我们以前就出过这样的问题（意料之外，没监控，没及时发现），代价是把 id 列修改成字符串临时解决了（很不好的实践）。

@8355 所以感觉 6 楼像一本正经的胡说八道。。


@RedisMasterNode 业务量大，一般至少会用 `bigint` 吧？`bigint` 不会这么容易用完吧。。

@wxf666 嗯其实我们故障的时候用的就已经是 bigint 了，正常用它确实是用不完的，但是那时候因为一些 bug ，浪费的 id 远比使用的多，频繁回滚等操作（具体忘记是什么不当操作了）导致浪费掉的 id 超过 99%，这是意料之外的事情了。

咱意思就是，在代码有问题的时候，其实不能假设譬如浪费掉了一半的 id ，而是很可能回滚、浪费了上百个 id 才实际写入了 1 个 id

这就跟内存泄露一样的，我认为我的应用只会使用 4GB 内存，我给机器分配了 32G 内存，就算应用有问题，开销翻倍，翻 3 倍，最多也就 10 多 GB 。但实际上不是，一旦出现意外，32G 内存全都用完了，自增 id 也是一个道理。

@edis0n0 请问你这个方案怎么做的，先预生成 id 吗？

@WilliamYang #27 分布式 ID 生成器