2

我有一个表，其中一列存储图像 src，它是散列值，并且散列值是从 microtime() 生成的，现在我有两种选择直接在数据库中存储散列值或存储派生图像名称的 bigint microtime .这将使我的数据库更快。

4

2 回答 2

1

我们必须从各个方面对此进行分析，以评估会导致哪些速度故障。

我会做几个假设：

  • 该数据将用作标识符（主键、唯一键、复合键）；
  • 此数据用于搜索和连接；
  • 您正在使用一种哈希算法，例如 SHA1，它会产生 40 个字符的十六进制编码数据字符串（MD5 会产生一个 32 个字符的十六进制编码数据字符串，如果您使用的是 MD5，则所有这些都可以适应 MD5）；
  • 您可能有兴趣将哈希的十六进制值转换为二进制，以减少一半所需的存储空间并提高比较速度；

在应用程序端插入和更新：

正如@Namphibian 所说，由 BIGINT 的 2 个操作和 CHAR 的 3 个操作组成。

但在我看来，速度差异真的没有那么大。您可以运行 10.000.000 次连续计算（在一个while循环中）并对它们进行基准测试以找出它们之间的真正差异。

此外，应用程序代码中的速度差异会线性影响用户，而 DB 中的速度差异会在流量增加时对用户产生非线性影响，因为重叠的写入必须相互等待，而一些读取必须等待写入完成。

在数据库端插入和更新：

BIGINT 与 CHAR(40) 或 BINARY(20) 几乎相同，因为更严重的时间消耗是等待访问磁盘而不是实际写入磁盘。

在数据库端选择和加入：

与 CHAR(40) 或 BINARY(20) 相比，BIGINT总是更快，原因有两个：

  • BIGINT 以 8 个字节存储，CHAR(40) 以 40 个字节存储，BINARY(20) 以 20 个字节存储；
  • BIGINT 的连续增加特性使其可预测且易于比较和排序。

第二个最佳选择是 BINARY(20)，因为它节省了一些空间，并且由于长度减少而更容易比较。

BINARY(20) 和 CHAR(40) 都是散列机制的结果并且是随机的，因此比较和排序平均需要更长的时间，因为索引中的随机数据（对于 btree 索引）需要更多的树遍历来获取（i表示在多个值的上下文中，而不是单个值）。

于 2012-06-25T08:24:37.400 回答
0

一个重要的科学原则可能适用于此：不要丢失原始数据。你永远不知道你可能需要它来做什么。

于 2012-06-25T10:39:21.357 回答