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

在 SQL 数据库中，使用 UUID（通用唯一标识符）作为主键既有优点也有缺点。虽然 UUID 在某些情况下有优势，但出于以下原因，它们可能并非主键的最佳选择：

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

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

可读性和调试性：
与整数不同，UUID 不易被人类读取，这会增加数据库的调试和手动检查难度。对于开发人员和数据库管理员来说，整数或其他较小的数据类型可能更方便。

聚类：
UUID 被设计为全局唯一，但不保证其顺序性。这种顺序性不足可能会导致磁盘 I/O 模式不佳，从而影响某些类型查询的性能，尤其是涉及范围搜索的查询。

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

存储开销：
存储 UUID 会增加存储需求，包括磁盘空间和内存。在存储成本至关重要的环境中，这可能是一个值得关注的问题。

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