截至 2018 年，使用 bigint 而不是 int 作为 Postgres 中的主键是否有任何性能差异？答案

【问题标题】：As of 2018, is there any performance difference by using bigint instead of int as a primary key in Postgres?截至 2018 年，使用 bigint 而不是 int 作为 Postgres 中的主键是否有任何性能差异？
【发布时间】：2018-10-26 00:39:16
【问题描述】：

我想在我的许多表（用户表、帖子表等）中使用随机主键，就像 medium.com 的设计一样（查看 url 或 api 中的文章 id ，它是一个 12 个随机十六进制字符字符串，很可能对应于一个 64 位整数），通过这种设计，我获得了更大的空间，而且它也比使用串行主键来抵抗自动请求更安全一些，获得有关网站的信息，例如帖子总数或用户总数或抓取

由于现在存储差异并不那么重要，是否会出现主要的性能差异，尤其是在获取查询方面，或者在 2018 年是否非常微不足道，尤其是如果 Postgres 托管在 RDS 之类的东西上？

【问题讨论】：

这个问题太宽泛了——如何才能对未指定硬件上未指定平台的性能发表一些看法？这不是愚蠢，而是不可能给出一个好的答案。我期望 SELECT 的性能不会显着提高，但是生成这些键（您没有显示）的代码可能比使用序列慢得多.我承认我不明白你期望的优势。
我说的是postgres主键搜索算法。生成密钥的代码呢？这是一个大问题吗？它只是从软件级别随机生成并转换为 64 位整数的随机 12 十六进制字符。
我不明白你为什么将一个 12 字节的十六进制数字“编码”成一个 bigint？你没有得到任何东西 - 你只有首先生成一些十六进制数字然后将其转换为 bigint 的缺点 - 为什么不使用 bigint 开始呢？以及如何“获得更大的空间”？您将其存储在 bigint 中，因此您受到 bigint 可以存储的范围的限制。至于原始查询性能，我认为不会有太大差异
测试原始性能的一种方法是使用pgbench 运行所有键都是整数，然后更改表以将它们存储为 bigint 并重复测试
我仍然怀疑滚动您自己的序列生成器是否值得。而且我不购买“安全”方面 - 默默无闻的安全永远不会真正起作用。无论数字是否按顺序排列，您仍然需要实施必要的安全检查。因此，实施安全系统的工作不会因此而减少，但您最终会遇到数字生成瓶颈，这很可能会影响系统的整体性能。

标签： sql postgresql primary-key biginteger

【解决方案1】：

有任何性能差异吗？是的。串行密钥为 4 个字节，而您的密钥为 8 个字节。那是更多的空间，因此需要更多的工作。

这有什么不同吗？可能不是。一些数据库会按主键对数据进行聚类（即排序）。 Postgres 不这样做。这种聚类是一个问题，因为它会立即导致随机生成的密钥碎片化。

您提出的关键结构似乎有一个很好的用例。虽然我没有看到它的先验问题，但您可能需要测试差异以查看它对您的应用程序是否重要。

【讨论】：

谢谢！我并不真正关心大小差异，因为在今天的存储中成本差异微不足道，我只关心获取请求的延迟。另一个问题：在搜索算法方面，搜索随机分布的索引（例如在我的情况下通过随机主键搜索）通常比串行索引更快还是更慢？
@plsno 。 . .它们使用基于树的索引（通常）存储，因此值的顺序不会有所不同。