使用自动增量ID或sha1散列的主键mysql？

我可以有一个自动增量id字段作为我的主键或sha1哈希。使用自动增量ID或sha1散列的主键mysql？

我应该选择哪一个？

在性能方面哪个更好？

来源

2012-05-26 cgwebprojects

你应该选择哪一个取决于你的应用。就性能而言，我会选择不需要计算昂贵散列的选项。 – eggyal

我的2表涉及一个sha1散列被存储，涉及每一行，我问作为varchar（40）列在2个表我认为是比1 varchar（40）和2个int列更detrement。 – cgwebprojects

@cgwebprojects 2 char（40）（不需要varchar）是80字节（取决于字符集）。 1个字符（40）和2个整数是48个字节。而且，索引在整数上比在char上要快（40）。 – Corbin

几乎肯定是一个自动递增整数。创建速度更快，搜索速度更快，体积更小。举个例子，如果你有另一个引用它的表。你想让它通过一个整数主键或通过sha1散列来引用它吗？一个整数会更有意义（以某种方式），并且它会更加有效（太多了！）。

来源

2012-05-26 05:35:37 Corbin

再次感谢！正如我在一张桌子上存放一个sha1，我不知道是否用相同的sha1将它连接到另一个，但是如果自动增量更好，那就这样吧！ – cgwebprojects

自动递增ID与通过sha1哈希链接相比更适合RDBMS的设计。积分ID很小，非常快速地索引和递增，对于DB来说非常便宜。 sha1会做出更大更慢的指标，正如juergen d指出的那样，它们很容易发生碰撞。（他的回答实际上应该是可以接受的答案，因为它涵盖了我所做的一切+碰撞） – Corbin

你能想象使用自动增量ID对数据库进行分片吗？其实不，你不知道;因为Instragram已经通过了它：http://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram自动增量ID是可笑的缩放。 – mjsa

使用自动增量ID。

一个ID不必生成只增加。
散列更适合存储密码。
您可以使用SHA哈希得到重复的密钥。这个机会很小但是真实。
一个ID更方便可读
ID是一种插入历史记录。你知道最后插入了哪条记录（最高ID）

来源

2012-05-26 05:35:24

非常感谢你的朋友:) – cgwebprojects

你可能会很快达到可以存储在一个整数的限制，比发现碰撞与SHA哈希。再次遇到阴影数据库时，自动增量会变得很痛苦。 – mjsa

有几个应用程序驱动的情况下，你想使用一个全球唯一的ID（UUID/GUID）：采用分片策略

你希望（或者）扩展写入。您不希望分片节点重复键。
你想成为能够安全端口数据从一个节点到另一个保存键。如果您想保持外键关系，这是至关重要的。
您的应用程序也可以用来离线（家用销售，家用维修等），其中离线应用周期性地与“真理之源”同步。您希望这些离线密钥是唯一的，无需进行远程呼叫。否则，您需要制定策略来重新整理密钥和关系。采用自动增量策略并根据您使用的RDBMS，这可能是一项不重要的任务。

如果你没有从上面或类似的东西用例，您可以使用自动递增的ID，如果让你舒服;但是，您可能仍然要考虑UUID/GUID

权衡：

有很多持有约UUID/GUID键的速度/大小的意见。在一天结束时，这是一种折衷，有很多方法可以通过数据库获得或减少速度速度。理想情况下，您希望将索引存储在RAM中以尽可能快;然而，这是一个权衡，你必须权衡其他考虑因素。

关于UUID/GUID其他注意事项：

许多RDBMS可以产生UUID。
您也可以通过您的application生成UUID（您并未绑定到要生成的RDBMS）。
开发人员/测试人员可以轻松地将数据从环境移植到环境，并使应用程序按预期工作。这是一个经常被忽视的用例;然而，这是使用UUID/GUID策略的更强有力的例子之一。
有些数据库针对脱机使用进行了优化（CouchDB），其中UUID就是您所得到的。

来源

2012-05-26 05:53:39

使用自动增量ID或sha1散列的主键mysql？

回答

相关问题