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