为CLOB字段添加SHA-256哈希的显式列是否会改善该CLOB字段

Question

我们需要实现一个表（可能是一个orable db table或mssql db table），如下所示：

1. 一列存储字符串值，此字符串值的长度高度可变，通常从几个字节到500兆字节（偶尔超过1千兆字节）
2. 基于上面，我们决定在db中使用CLOB类型。（以某种方式使用系统文件不是一个选项）
3. 该表非常大，可达数百万条记录。
4. 针对此表的最常见和最重要的操作之一是通过此CLOB列搜索记录，并且搜索字符串需要EXACTlY匹配此CLOB列值。

我的问题是除了在CLOB列上添加索引之外，我们是否需要进行一些特定的优化以提高搜索性能？

我的一位团队成员建议添加一个额外的列来计算上面CLOB列的SHA-256哈希值，并按此哈希值而不是CLOB列进行搜索。就他的观点而言，这样做的理由是哈希值是等于变量的长度，因此对其进行索引会使搜索更快。

但是，我不认为这种方式有很大的不同，因为假设添加显式哈希提高了搜索性能数据库应该足够智能，可以自己做，可能将此哈希值存储在db系统的某些隐藏位置。为什么我们开发人员明确地这么做呢，另一方面，这个哈希值理论上会产生碰撞，尽管它很少见。

我能想到的唯一好处是，当数据库的客户端搜索关键字非常大时，可以通过将此大值散列到较小的长度值来减少网络往返，因此网络传输速度更快。 / p>

所以任何数据库大师，请阐明这个问题。非常感谢！

Answer 1

常规索引不适用于CLOB列。相反，您需要创建一个Oracle Text索引，主要用于关键词/短语的全文搜索，而不是全文匹配。

相反，通过计算列数据的哈希函数，您可以在哈希值上创建索引，因为它足够短以适合标准的VARCHAR2或RAW列。在尝试查找完全匹配时，这样的哈希函数可以显着减少搜索空间。

进一步你对哈希冲突的关注，虽然没有根据，但可以减轻。首先，哈希冲突相对较少，但是当它们确实发生时，文档不太可能非常相似，因此可以在检测到冲突的情况下使用直接文本比较。 A 或者由于哈希函数的工作方式，原始文档的小变化会导致哈希值发生重大变化，而且对不同文档的相同更改会对哈希值产生不同影响，您可以计算原始文本的子集（或超集）的二级哈希，用作冲突避免机制。