有没有理由不在数据库表的索引上使用auto_increment？

Question

我继承了维护编码非常糟糕的电子商务网站的任务，我正在努力重构大量代码并尝试修复持续存在的错误。

每个数据库插入（将项目添加到购物车等）都以grab_new_id函数开始，该函数COUNT表中的行数，然后从该数字开始，查询数据库以查找未使用的索引号。除了性能非常糟糕（已经有40,000多行，并且索引被定期删除，因此有时需要几秒才能找到新的id）这会在两个操作同时执行时定期中断，因为添加了两个条目重复的身份证号码。

这对我来说似乎很愚蠢 - 为什么不在索引字段上使用自动增量？我已经对它进行了两种测试，并且在没有指定索引ID的情况下向表中添加行（显然）要快很多倍。我的问题是：任何人都可以想到原始程序员可能做到这一点的任何原因吗？是否有一些思想流派将auto_increment视为不良形式？是否有没有自动增量功能的数据库？

Answer 1

我之前从一个不知道该功能存在的人那里看过这个。绝对使用自动增量功能。

有些人会采用“自己动手”的方式处理所有事情，通常是因为他们没有花时间去查看这是否是可用的功能，或者其他人是否已经提出它。您经常会看到这些人疯狂的变通办法或表现不佳/脆弱的代码。继承糟糕的数据库根本不好玩，祝你好运！

Answer 2

根据我的理解，Oracle有序列但不是自动生成的ID。但是，通常这种东西是由那些不了解数据库编程并且不愿意看到数据缺口的开发人员完成的（当你从回滚中获得）。还有人喜欢创建id，因此他们可以将它用于子表，但是大多数具有自动生成ID的数据库也有一种方法可以在创建时将该id返回给用户。

Answer 3

我发现针对auto_inc字段的唯一合理（但完全可以避免！）的问题是，默认情况下，某些备份工具将auto_inc值包含在表定义中，即使您不将数据包含到可能不方便的db转储中也是如此。

Answer 4

根据具体情况，很明显有很多理由不使用连续数字作为主键。

然而，在我做希望连续数字作为主键的情况下，我认为没有理由不使用MySQL提供的内置auto_increment功能

Answer 5

他们可能只是缺乏经验并且不熟悉自动增量。我能想到的一个原因，但并不一定有意义，是在使用自动增量ID时，很难（并非不可能）将数据从一个环境复制到另一个环境。

出于这个原因，我之前使用顺序Guids作为我的主键，以便于转换数据，但计算行来填充ID有点WTF。

Answer 6

出于历史原因，这可能是这样做的;即早期版本没有autoinc变量。我编写的代码在不支持autoinc类型的数据库上使用手动autoinc字段，但我的代码效率不如引用count（）那么低效。

将autoinc字段用作主键的一个问题是，将记录移入和移出表可能会导致主键发生变化。因此，我建议预先在“LegacyID”字段中进行设计，以便在将记录移入和移出表格时将其用作主键的未来存储。

Answer 7

需要注意两件事：

1.您的RDBMS会在重启时智能地设置自动增量值。我们的工程师正在滚动自己的自动增量键，以便在服务器重新启动时绕过自动增量字段跳转100000次。但是，Sybase在某些时候添加了一个设置自动增量大小的选项。

2.如果您正在复制数据库并使用主 - 主配置，那么自动增量可能变得令人讨厌的另一个地方。如果你在两个数据库上写（不建议），你可能会遇到身份碰撞。

我怀疑其中任何一种情况都是如此，但需要注意的事项。

Answer 8

我可以看到id是否是在客户端上生成并推送到数据库中，这是常见的做法，当速度是必要的，但你所描述的似乎是顶部和不必要的。删除它并启动自动递增ID。