双整数作为数据库 ID 是否比字符串代码更有效？答案

【问题标题】：Are double integers more efficient as database IDs than string codes?双整数作为数据库 ID 是否比字符串代码更有效？
【发布时间】：2014-09-03 00:42:51
【问题描述】：

此问题与超过 100 万行的 MySQL 数据库或表有关。

由于每一行都应有一个唯一的 ID（或代码），稍后用于创建多个表之间的关系，因此使用双整数 ID（例如“1456156148489418189”而不是字符串代码，例如“ds156b1dsb4ds8b4sd6b14s864ea”。

例如 JOIN 甚至 SELECT 在超过百万行的表中搜索双整数是否比搜索字符串更容易？如果是这样，是否存在一些相关性，例如 40 位双整数作为 UID 的效率比使用 20 个字符串的效率高 50%？

【问题讨论】：

为什么要加倍？ usigned int 可以在 4 个字节中保存 40 亿条记录，其中 double 是空间的两倍，即使如此，您仍然可以使用与 double 一样大的 bigint 来代替。此外，您在实际使用的需要索引的列上是否有适当的索引。还有诸如分区之类的事情会极大地影响速度。 是的，在 90% 的情况下，int 索引比字符串索引快。
我会使用最容易使用的那个。性能上的差异不太可能很大。所有其他事情都相似，我会使用 numeric 选项，因为每个 IO 页面的索引条目会更大，如果 32 位足够大，则优先使用 32 位整数而不是 64 位整数
Prix：我想使用一个随机数，在用户界面输出中使用 auto_incremented id 让我不寒而栗。 user3351494：是的，我认为大整数应该足够了

【解决方案1】：

如果您的 id 仅用于主键而不是在用户界面中显示，则使用自动增量而不是字符串

【讨论】：

【解决方案2】：

只需使用 int 作为您的 ID 并将其设置为自动递增 :)

【讨论】：

正如沉沉指出的那样，在 UI 输出中使用 auto_incremented 值并不是一个好习惯，而对 UI 和表关系使用不同的值往往会变得混乱。这种方式是不是一种不安全的坏习惯？

【解决方案3】：

使用诸如“1456156148489418189”之类的双整数ID是否更有效

算了。您无法将该值准确地拟合为双精度值。不超过大约 15.9 个十进制数字。

您可以使用 64 位整数，但请注意您期望的位数。最大值为 9223372036854775807。

【讨论】：