实现 UUID 以获得更好的性能

Question

要求：
我们需要为商家分配一个随机的、足够长的数字/字符串，以便它们是唯一可识别的（不希望有人猜测标识符）。这是必需的，因为我们将此数字/字符串打印为二维码并将其提供给商家，以便我们的用户可以读取二维码并获取有关商家的信息。

当前实施：
我们无法打印 id，因为它们是连续的，因此我们引入了一个新字段（externalId）来存储由 JUG UUID 生成器的 TimeBasedGenerator 生成的唯一 id。随着研究的深入，我发现 UUID 存在性能问题。所有文章都谈到 UUId 作为主键，我没有使用 UUID 作为主键，而是作为辅助标识符。我不担心插入和更新，因为与搜索相比它们会更少。由于用户将从打印的二维码中读取的 UUID 发送给我们，我们需要使用此 UUID 字段搜索商家，因此会对性能产生巨大影响。

根据我的解决方案：
我们将给出 ID:UUID 的组合，而不是 UUID，这样当我们收到请求时，我们可以使用 ID 拆分和获取商家，并检查我们数据库中存在的 externalId(UUID) 是否与提供的匹配，如果匹配否则我们不会退回商家。

此解决方案是否会显着提高性能，或者字符串操作所花费的时间将使效果无效。

有没有更好的方法来做到这一点？

谢谢

Answer 1

最佳实现取决于您的 UUID 的字符分布，但我在遇到类似情况时所做的只是为最终用户使用 UUID。在数据库中，我添加了一个用 UUID 的前 2 个字符填充的列，并为该列建立了索引。

无论是这个还是按照您的建议，ID 都可以达到相同的目的。索引部分 UDID 的好处是

1. 您可以调整使用多少字符来提高性能
2. id 未在外部使用，可能会导致问题。

另一方面，整数索引可能使用较少的内存并且不需要调整

性能方面，在我的实施中，我们面临百万分之一的搜索查询需要 7-8 秒。有了这个解决方案，我们的时间缩短到了几毫秒

Answer 2

UUID 以各种形式生成。您可能已经知道，RFC 4122 概述了一个定义五个不同版本的 variant（即 UUID 模式）。我建议您查看 RFC 4122 的 version 1。

版本 1 使用生成 UUID 的机器的 MAC 地址作为生成的 UUID 的最后 12 位数字。

假设您去二手电脑回收商购买过时的以太网适配器；启动它并获取该适配器的 MAC 地址；然后销毁适配器（碎纸机、霰弹枪、酸液等）。您现在可以放心，宇宙中没有其他计算机会使用该 MAC 地址生成 V1 UUID。

现在您可以编写一个 UUID (RFC 4122, V1) 生成器，该生成器将使用获取的 MAC 地址。

您可以为每个商家获取一个单独的 MAC 地址（来自其他卡），然后您就可以识别为每个商家生成的 UUID。

奖励： 您可以使用 Mahonri Moriancumer's UUID and GUID Generator and Forensics 来试验 V1 UUID。