我正在开发一个应用程序，该应用程序将十六进制值实现为业务键（除了自动增量字段作为主键），类似于Gmail中显示的URL ID。我将在列中添加一个唯一约束，并且最初考虑将值存储为bigint以避免搜索varchar字段，但是如果该字段是唯一的，则想知道是否有必要。
内部联接将使用自动增量字段完成，十六进制值将在where子句中用于过滤。
将值作为varchar（x）或者char（x）存储到执行转换为十六进制和从十六进制转换以将值存储为整数的其他工作时，会产生什么样的性能影响？数据库？是否值得增加复杂性？
我对少量行（50k）进行了快速测试，搜索结果时间也相似。如果存在大的性能问题，它会是线性的还是指数的？
我正在使用InnoDB作为引擎。
答案 0 :(得分：5)
您的十六进制值是GUID吗？虽然我过去担心像索引这样长项的性能，但我发现在现代数据库中，甚至数百万条记录的性能差异都相当微不足道。
一个可能更大的问题是索引占用的内存（例如，16字节比4字节int），但在我控制的服务器上，我可以为此分配。只要索引可以在内存中，我发现其他操作有更多的开销，索引元素的大小不会产生明显的差异。
从好的方面来说，如果你使用GUID，你可以获得所创建记录的服务器独立性，并且可以更灵活地合并多个服务器上的数据（这是我关心的，因为我们的系统聚合来自子系统的数据）。
这篇文章的图表似乎支持了我的怀疑：Myths, GUID vs Autoincrement
答案 1 :(得分：1)
十六进制值是从UUID（Java的实现）生成的;它被散列并截断为较小的长度（可能是16个字符）。其算法仍在讨论中（目前为SHA）。我看到以十六进制与整数存储值的一个优点是，如果我们需要增加大小（我不认为这个应用程序在16个字符处发生）我们可以简单地增加截断长度并保留旧值而不用担心碰撞转换为整数值对它来说效果不会很好。
截断与仅使用GUID / UUID的原因只是使URL和API（这些将被使用的地方）更加友好。
答案 2 :(得分：1)
在其他条件相同的情况下，保持较小的数据会使其运行得更快。主要是因为它占用的空间更少，磁盘i / o更少，保存索引所需的内存更少等等.50k行不足以注意到这一点......