这是针对潜在大型数据库的最佳实践问题。
我有一个暴露给公共(public) API 的表，它将存储与每一行关联的 UUID。 此 UUID 是公众能够搜索表中数据的唯一方式。
UUID 在外部使用，因为内部不需要增量 ID，并且它为数据提供了额外的安全层。 数据库中的其他任何地方都没有引用此行。
最初，我创建的表没有自动增量 (int) ID 列，而是将 BINARY(16) UUID 列设为主键。
但是，我做了一些更多的阅读，并看到一种观点，在大型数据集中，非顺序主键的存储和 IOps 比仅使用顺序主键呈指数级增长，因为插入方法需要更多操作在 B+ 表上找到正确的行。
我不了解 MySQL/InnoDB 的内部工作原理，所以我的问题是:
拥有一个自动递增的 INT(4)/BIGINT(8) 主键——以及 BINARY(16) 唯一键 == 或 == 只是“更好”吗？当面对潜在的大数据集时，使用非增量 BINARY(16) 作为主键？
谢谢， 日本
最佳答案
您的数据会比 RAM 大吗？如果是这样，UUID 的随机性就会成为性能问题。
大多数访问都是通过“最近发布的”ID 进行的吗？如果是这样，按时间顺序排列的东西的好处是可以将感兴趣的 id 聚集在一起，从而改善缓存。
您是否有单独的、独立的客户端生成 ID？如果是这样，您需要 UUID 或发布 id 的通用服务器。
您有很多辅助 key 吗？请注意，每个二级索引都有主键列的副本，因此会因大 PK 而增加。 (在某些情况下，这是人工 auto_inc PK 的一个论据。)
关于mysql - 如果您有 UUID 字段，是否仍应使用基于 INT 的主键，并将 UUID 设置为唯一键，还是仅将 UUID 设置为主键？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/68176065/