考虑性能和友好 URL 时要实现的数据库密钥设计

Question

简介

所以我最近问了一个question on the information security stack exchange，这让我决定我不想在外部公开自动递增的整数 ID不是因为安全原因，而是因为我认为它会是让用户得出有多少学生在他们之前注册的结论非常令人不安。

---

问题

但这导致我做出另一个决定，如果我要使用 GUID 或其他某种随机生成的字符串 id，我应该将其用作主键吗？由于我选择的 RDBMS 是 MySQL，选择的数据库引擎是 InnoDB，in InnoDB the primary key is always clustered，并且所有其他索引都是非集群的。如果我将 GUID 设为主键，我会得到非常 bad performance with a higher number of inserts。

---

建议的解决方案

所以我正在考虑为所有表保留自动递增的整数 id，同时将我的所有外键保留为整数 id，但还要为每个表添加一个唯一索引来存储 GUID，这将暴露在外。然后每次我在我的 API 中收到一个请求，并且我想将 Student 表与数据库中的 Books 表连接起来，我需要做的第一件事就是查询数据库以找出整数 id用于指定的学生 GUID。

既然我认为我绝对不是第一个遇到这个问题的人，或者类似的人，这是解决我的问题的最佳方法吗？

Answer 1

是的，这是合理的。

将 GUID 作为二级索引，使用INT AUTO_INCREMENT 将低效部分限制为该索引。建议您打包 GUID——而不是 CHAR(36) CHARSET ascii（始终为 36 字节），将其打包为 BINARY(16)（始终为 16 字节）。加上一个 4 字节的 INT，一百万学生可能需要 50MB。与您的多 GB 磁盘相比很小？

为了最小化开销，只需将 GUID 设置为 Students 表上的辅助键。这主要消除了“我需要做的第一件事就是查询数据库......”的额外步骤。

替代方案：

• 一个随机数。更小，但需要避免重复。
• AUTO_INC 的加盐和散列函数。