Mysql 存储哈希值和生成哈希值的bigint变量哪个更好

我有一个表，其中一列存储哈希值中的图像src，该哈希值由microtime（）生成，现在，我有两种选择：直接将哈希值存储在数据库中，或者存储从中派生图像名称的bigint microtime。这将使我的数据库速度更快。

我们必须从各个方面分析这一点，以评估产生的速度故障

我将作出一些假设：

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

在应用程序端插入和更新： 如@Namphibian所述，它由2个用于BIGINT的操作和3个用于CHAR的操作组成

但在我看来，速度的差别并没有那么大。您可以运行10.000.000个连续计算（在

while

循环中）并对它们进行基准测试，以找出它们之间的实际差异

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

在数据库侧插入和更新： 对于BIGINT和CHAR（40）或二进制（20）几乎是一样的，因为更严重的时间消耗是等待访问磁盘而不是实际写入磁盘

在DB侧选择和加入： 与CHAR（40）或BINARY（20）相比，BIGINT的速度总是更快，原因有二：

• BIGINT存储在8字节中，CHAR（40）存储在40字节中，BINARY（20）存储在20字节中
• BIGINT的连续增长特性使其具有可预测性，并且易于比较和排序

第二个最好的选择是二进制（20），因为它节省了一些空间，并且由于减少了长度，比较起来更容易

---

二进制（20）和字符（40）都是散列机制的结果，并且是随机的，因此比较和排序平均需要更长的时间，因为索引中的随机数据（对于btree索引）需要更多的树遍历来获取（我的意思是在多个值的上下文中，而不是单个值）.

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

我怀疑它会对速度产生任何影响，除非hashcode数据类型比time数据类型短得多，但一个重要的科学原则可能适用于此：不要丢失原始数据。你永远不知道你需要它做什么。我不明白你怎么能从我说的话中推断出来。我赞成的恰恰相反。本例中的“原始数据”显然是生成哈希的微时间。nice但bigint为8字节。关于上载文件的时间戳不是原始数据，而是元数据。原始数据将是上传文件的原始文件名。我也同意应保留原始数据。因此，将原始图像名称与标识符（为索引和检索而优化的标识符）一起存储将是我的选择。