unique varchar字段与unique bigint的MySQL性能

我正在开发一个应用程序，它将实现一个十六进制值作为一个业务键（除了一个作为主键的自动增量字段），类似于Gmail中的URL id。我将向列中添加一个唯一约束，最初考虑将值存储为bigint，以避免搜索varchar字段，但想知道如果字段是唯一的，是否有必要这样做

内部联接将使用自动递增字段完成，十六进制值将在where子句中用于筛选

简单地将值存储为varchar（x）或char（x）会对性能造成什么样的影响？在执行与十六进制之间的转换以将值存储为数据库中的整数时，可能需要额外的工作？它值得额外的复杂性吗

我在少量行（50k）上做了一个快速测试，并且有相似的搜索结果时间。如果存在较大的性能问题，是线性问题还是指数问题

---

我使用InnoDB作为引擎。

您的十六进制值是GUID吗？虽然我曾经担心索引等长项目的性能，但我发现在现代数据库中，即使是数百万条记录的性能差异也相当小

一个可能更大的问题是索引消耗的内存（例如，16字节vs 4字节int），但在我控制的服务器上，我可以为此分配内存。只要索引可以在内存中，我发现其他操作的开销就更大，索引元素的大小不会产生明显的差异

从好的方面来说，如果使用GUID，则可以获得创建记录的服务器独立性，并在合并多个服务器上的数据时获得更大的灵活性（这是我关心的，因为我们的系统会聚合来自子系统的数据）

---

本文中的一个图表似乎支持了我的怀疑：

十六进制值是从UUID（Java的实现）生成的；它被散列并截断为更小的长度（可能是16个字符）。其算法仍在讨论中（目前为SHA）。我看到用十六进制vs整数存储值的一个优点是，如果我们需要增加大小（我看这个应用程序在16个字符时不会发生这种情况），我们可以简单地增加截断的长度，保留旧值，而不必担心冲突。转换为整数值并不能很好地实现这一点

---

截短与简单使用GUID/UUID相比，其原因仅仅是为了使URL和API（将使用它们的地方）更友好

在所有其他条件相同的情况下，保持数据较小将使其运行更快。主要是因为它会占用更少的空间，因此磁盘i/o更少，保存索引所需的内存更少，等等。50k行不足以注意到，尽管…

个人而言，我确实试图避免用户在用户界面中暴露于GUID。甚至是一个URL行。但是，我建议在内部使用它们，并通过使用会话或使用特定代码来截断它们以供显示。这样，&item=1是我显示的第一个项目。。。我在内部拉GUID。