MySQL的性能VS独特BIGINT

我的工作将要实施的十六进制值作为业务键（除了自动增量字段作为主键）类似于在Gmail中看到的URL ID的应用。我将为该列添加一个唯一的约束，并且最初考虑将该值存储为bigint以避开搜索varchar字段，但是想知道如果该字段是唯一的，那么这是否是必需的。MySQL的性能VS独特BIGINT

内部连接将使用自动递增现场完成和十六进制值将在where子句过滤中使用。

简单地将值存储为varchar（x），或者将char（x）存储在额外的工作中，以执行向和从十六进制的转换以将值存储为整数在数据库中？这值得额外的复杂性吗？

我做了少量的行（50K）的快速测试和有类似的搜索结果的时间。如果存在很大的性能问题，它会是线性的还是指数级的？

我使用InnoDB作为引擎。

来源

2009-02-04 ahanson

您的十六进制值是GUID吗？尽管我过去担心诸如索引这样的长项目的表现，但我发现在现代数据库上，甚至数百万条记录的性能差异也是微不足道的。

一个潜在的更大的问题是所述存储器，所述索引消耗（16字节对4字节整型，例如），但对我控制我可以分配用于该服务器。只要索引可以在内存中，我发现其他操作的开销更大，索引元素的大小没有显着差异。好处在于，如果您使用GUID，您可以获得创建记录的服务器独立性，并且可以更灵活地合并多个服务器上的数据（这是我关心的，因为我们的系统会汇集来自子系统的数据）。

有，似乎备份我怀疑这篇文章的图：Myths, GUID vs Autoincrement

来源

2009-02-04 20:59:04 Godeke

从UUID（Java的实现）所产生的十六进制值;它被散列并截断为较小的长度（可能是16个字符）。算法仍在讨论中（目前是SHA）。我看到的以十六进制和整数形式存储值的优点是，如果我们需要增加大小（在16个字符处我没有看到这个应用程序发生的情况），我们可以简单地增加截断的长度并保留旧值而不用担心的碰撞。转换为整数值不会很好地工作。

的原因截断VS只需使用GUID/UUID是仅仅为了使网址和API（这是它们将被使用）更加友好。

来源

2009-02-04 22:02:00 ahanson

就个人而言，我真的尽力避免将用户暴露给用户界面中的GUID。即使是一个URL线。但是，我会建议在内部使用它们，并通过使用会话或使用特定的代码来截断它们以显示*。这样＆item = 1是我展示的第一个项目...我在内部拉* GUID *。 – Godeke 2009-02-05 00:08:51

其他所有条件都相同，保持数据更小会使其运行更快。这主要是因为它会需要更少的空间，磁盘，以便减少I/O，内存少需要保存索引，等等等等50K行是不够的，注意到虽然...

来源

2009-02-05 09:46:03

MySQL的性能VS独特BIGINT

回答

相关问题