为什么永远不应该使用 UUID 作为 SQL 数据库中的主键？

在 SQL 数据库中使用 UUID（通用唯一标识码）作为主键既有优点也有缺点。虽然 UUID 在某些情况下具有优势，但它们可能不是主键的最佳选择。

UUID全称：Universally Unique Identifier，即通用唯一标识码。

在 SQL 数据库中使用 UUID作为主键既有优点也有缺点。虽然 UUID 在某些情况下具有优势，但它们可能不是主键的最佳选择，有以下几个原因：

• UUID 的长度为 128 位，而典型整数的长度为 32 位。较大的大小可能会导致存储需求增加和性能下降，尤其是在处理大型数据集时。

• 基于 UUID 列构建的索引的执行效率可能不如基于较小数据类型的索引。这是因为较大的键可能会导致更多的页面读取，从而影响查询性能。

• 与整数不同，UUID 不是人类可读的，这使得数据库的调试和手动检查更具挑战性。整数或其他较小的数据类型对于开发人员和数据库管理员来说可能更方便。

• UUID 被设计为全局唯一，但不保证它们是连续的。缺乏顺序排序可能会导致磁盘 I/O 模式不理想，从而影响某些类型查询的性能，尤其是涉及基于范围的搜索的查询。

• UUID 通常是使用时间戳和随机值的组合生成的。这种随机性可能会导致更高级别的索引碎片，从而随着时间的推移影响数据库性能。

• 存储 UUID 可能会导致磁盘空间和内存方面的存储需求增加。在存储成本是关键因素的环境中，这可能是一个问题。

• 管理 UUID，尤其是它们在分布式系统中的生成和唯一性，可能会增加应用程序逻辑的复杂性。如果更简单的主键类型足以满足应用程序的要求，则可能不需要这种复杂性。