CHAR(64) 或 BINARY(32) 在 SQL SERVER 中存储 SHA256 哈希答案

【问题标题】：CHAR(64) or BINARY(32) To Store SHA256 Hash in SQL SERVERCHAR(64) 或 BINARY(32) 在 SQL SERVER 中存储 SHA256 哈希
【发布时间】：2013-09-11 04:02:06
【问题描述】：

我正在讨论在 SQL Server 中存储 SHA256 哈希时使用哪种数据类型。它应该是 CHAR(64) 还是 BINARY(32) ... 该列将是唯一聚集索引的一部分。我知道此时我可能会感到头疼，但是我想第一次就做到这一点，而且我知道有时原始数据类型更快，而其他时候更新更奇特的类型表现更好。（是的，我知道 char(64) 并不是那么新，但它比字节存储更新）

我环顾四周，在搜索等方面找不到任何关于一个与另一个的性能的信息。

【问题讨论】：

这有帮助吗？ stackoverflow.com/questions/252156/…
我会使用 binary(32) 只是因为我没有理由支持 char(64) - 我认为后者的唯一原因是所有工作几乎完全通过CLI（但是转换函数无论如何都可以用于人机交互）。以编程方式，处理原始数据同样容易，甚至更容易。它还导致空间稍微减少（-> 索引变得如此之小/比较速度如此之快），并且由于我不能为 char(64) 争论，所以不妨只享受免费的好处。
据我所见 binary(32) 在 char(64) 上有一点优势，我只会在 SQL 端使用该列。这里提到的等式的另一面是代码的可用性，但是我宁愿获得一点优势，如果真的存在的话，就吃掉额外的开发复杂性。所以.. 我将使用 BINARY(32)。 stackoverflow.com/a/16993150/128795

标签： sql sql-server

【解决方案1】：

你知道通过使用 CHAR(64)，即使你的键是“A”，每一行也会占用 64 位？我不打算讨论你使用字符串作为聚集索引的事实，我只是假设你有一个很好的理由，但是使用 CHAR 而不是 VARCHAR？您是否打算更新值？因为那将是我看到使用 char 而不是 varchar 的唯一原因

【讨论】：

一个 SHA256 散列将始终占用 64 个字符。因此 CHAR 与 VARCHAR。从上面的 cmets 我相信 BINARY(32) 是要走的路。我使用该哈希的原因是因为我有一些需要唯一的文本（ len 中的 2048 ），并且我可以比字符串表示更快地比较哈希，并且考虑到 SHA256 冲突的可能性很低，我得到了一个很好的性能提升。该表不是高度事务性的，或者不会在初始数据填充之后，但会经常读取。感谢您的想法，因此请随时回复/批评。
@kroolk SHA256 对于您的目的来说是非常过分的。如果您不介意四处寻找非内置的东西，您可以使用更快的非加密哈希。（GitHub 上有一个 .NET CityHash 库，但它确实涉及一个原生 DLL：github.com/gmarz/CityHash）
这个答案似乎错过或忽略了 OP 实际在做什么。当 OP 要求比较 CHAR 和 BINARY 时建议 VARCHAR 非常不合适。对于定长数据，定长类型总是更优越，OP 明确描述了定长算法。