使用 nanoid 作为主键有什么缺点吗？

Question

我知道 UUID 和递增整数通常用作主键。我正在考虑使用 nanoids，因为它们是 URL 友好的，而不是可猜测的/可强力抓取的（如递增整数）。

是否有任何理由不使用 nanoids 作为像 Postgres 这样的数据库中的主键？（例如：也许它们会大大增加查询时间，因为它们没有......对齐或其他什么？）

Answer 1

大多数数据库使用递增 id，因为将新值插入到基于 B 树的索引末尾会更有效。

如果将新值插入 B 树中间的随机位置，则可能必须拆分 B 树非终端节点，这可能会导致下一个更高级别的节点分裂，依此类推，直到B 树的顶部。

这也有更大的风险导致碎片，这意味着索引为相同数量的值占用更多空间。

该博客是关于 MySQL 的，但同样的问题也适用于任何基于 B 树的数据结构。

如果您已经决定必须使用 nanoid 作为面向人类的标识符，请将其作为非主键属性存储在表中。 (3认同)
从（略读）链接的文章来看，主要的性能差异似乎在于使用 UUID 或递增 id 之间。nanoid 与 UUID 不会有太大区别。 (2认同)
有些人修改标准 UUID 以确保它按时间戳排序。该博客描述了该技术：https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ 但您必须研究该技术是否可以应用于纳米机器人。我不知道纳米机器人如何编码其值，并且可能无法使用这种优化技术。 (2认同)