SQL - 最大 255 长度的唯一索引 - 哈希解决方案

Question

我们有存储用户令牌的表（即 accessTokens）。

问题是，有时令牌的长度可能超过 255，而 MySQL/MariaDB 无法将其存储到在该列上具有唯一索引的表中。

我们需要唯一索引，因此一种解决方案是添加具有最大 255 长度的令牌哈希的附加列，并为其添加唯一索引。任何搜索/保存都会经过这个哈希，匹配后，我们选择整个令牌并将其发回。经过大量思考和谷歌搜索，这可能是此用例唯一可行的解​​决方案（但您可以尝试再给我们一个）。

我们现在生成的每个令牌至少是部分随机的，因此哈希冲突的可能性很小，用户不会永远卡在下一个请求中，它应该通过。

你知道2017年有什么好的现代方法吗？有一些有关此方法的哈希冲突的统计数据将不胜感激。

哈希仅供内部使用 - 我们不需要它是安全的（快速不安全的哈希对我们来说是最好的），它应该足够长以降低冲突的可能性，但绝对不能超过 255 长度限制。

PS：设置允许更多长度的特殊版本的数据库/表是不可行的，我们在一些不迁移的旧系统中也需要它。

Answer 1

这些访问令牌是否可以用 8 位字符表示？也就是说，它们中的所有字符都是取自 ASCII 还是 iso-8859-1 字符集？

如果是这样，您可以通过使用COLLATE latin1_bin 声明访问令牌列来获得比 255 更长的唯一索引。索引前缀的限制是 767 个字节，但 VARCHAR 列中的 utf8 字符每个字符占用 3 个字节。

因此，具有 767 个唯一 latin1 字符的列应该是唯一可索引的。如果您的唯一哈希都适合大约 750 个字节，那可能会解决您的问题。

如果不是……

您已要求为具有“低”冲突风险的长令牌提供哈希函数。 SHA1 is pretty good，可作为 MySQL 中的一个函数使用。 SHA512 更好，但不适用于所有 MySQL 服务器。但问题是：获取长标记的第一个或最后一个 250 个字符并将它们用作散列的碰撞风险是多少？

我为什么要问？因为您的规范要求在对于 MySQL 唯一索引来说太长的列上使用唯一索引。您提议通过使用也不能保证唯一的散列函数来解决该问题。这为您提供了两种选择，这两种选择都要求您承受较小的碰撞概率。

1. 添加一个由SHA2('token', 512) 计算的hash 列，并承受极小的碰撞概率。
2. 添加一个由LEFT('token', 255) 计算的hash 列，并避免发生碰撞的可能性很小。

您可以简单地通过删除标记列上索引的唯一约束来实现第二个选择。 （换句话说，做的很少。）

SHA 具有众所周知的碰撞特性。要评估其他一些散列函数，需要知道长令牌的冲突特征，而您还没有告诉我们这些。

Answer 2

关于哈希的评论

UNHEX(MD5(token)) 适合 16 个字节 - BINARY(16)。

关于碰撞：理论上，在 9 万亿行的表中，9 万亿分之一的概率会发生碰撞。

对于BINARY(20) 中的SHA()，几率更小。在我看来，更大的 shas 太过分了。

超过 767 限制到 3072

⚈ 升级到 5.7.7 (MariaDB 10.2.2?) 限制为 3072 字节 - 但您的云可能不提供此功能；
⚈ 重新配置（如果使用 5.6.3 - 5.7.6（MariaDB 10.1？））——要改变 4 件事：梭子鱼 + innodb_file_per_table + innodb_large_prefix + 动态或压缩。

5.5 的更高版本可能会执行“重新配置”。

类似问题：Does MariaDB allow 255 character unique indexes?