介绍
所以我最近问了一个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 表时，我需要做的第一件事是查询数据库以找出指定学生 GUID 的整数 ID。
既然我假设我绝对不是第一个遇到这个问题的人，或者与此类似的人，那么这是解决我的问题的最佳方法吗？
最佳答案
是的，这是合理的。
将 GUID 作为二级索引，使用 INT AUTO_INCREMENT 将低效部分限制为该索引。建议您打包 GUID——而不是 CHAR(36) CHARSET ascii(始终为 36 字节)，将其打包为 BINARY(16)(始终为 16 字节)。再加上一个 4 字节的 INT，一百万个学生可能需要 50MB。与您的多 GB 磁盘相比很小？
为了最小化开销，只需将 GUID 设置为 Students 表中的辅助键。这主要消除了似乎是“我需要做的第一件事是查询数据库......”的额外步骤
备选方案:
- 一个随机数。较小，但需要避免重复。
AUTO_INC的加盐和散列函数。
关于mysql - 考虑性能和友好 URL 时要实现的数据库 key 设计，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/57830066/