通常，数据库的设计如下，以允许实体使用多种类型。
实体名称 类型 其他信息
实体名称可以是帐号和类型，例如银行数据库中的储蓄，当前等。
大多数情况下，type会是某种字符串。可能存在与实体类型相关联的其他信息。
通常会像这样提出查询。 查找此特定类型的帐号？ 查找类型为X的帐号，余额是否超过1百万？
要回答这些查询，如果索引与特定列关联，查询分析器将扫描索引。否则，它将对所有行进行完整扫描。
我正在考虑以下优化。 为什么我们不将每个列数据的哈希值或整数值存储在实际表中，以便维护排序属性，以便于比较。
它具有以下优点。 1.表格大小会少很多，因为我们将为每个列数据存储小尺寸值。 2.我们可以在每个列的哈希值上构造一个聚簇B +树索引，以检索匹配或大于或小于某个值的相应行。 3.通过在主存储器中具有B +树索引并检索相应的值，可以容易地检索相应的值。 4.永远不需要检索不常见的值。
我脑子里还有更多的优化。我将根据对此问题的反馈发布这些内容。
我不确定这是否已在数据库中实现，这只是一个想法。
感谢您阅读本文。
- 巴拉
更新
我不是想模仿数据库的功能。通常，索引由数据库管理员创建。我试图通过在数据库中的所有字段上建立索引来提出物理模式，以便减少数据库表的大小并且很容易回答几个查询。
更新:(乔的回答）
如何为每个字段添加索引减少数据库的大小？除了哈希之外，您还必须存储所有真值;我们不只是想查询存在而是想要返回实际数据。
在典型的表格中，将存储所有物理数据。但现在通过在每个列数据上生成哈希值，我只将哈希值存储在实际表中。我同意它不会减小数据库的大小，但它减小了表的大小。当您不需要返回所有列值时，它将非常有用。
大多数RDBMS现在可以有效地回答大多数查询（特别是在使用关键索引的情况下）。我很难制定出数据库效率更高，节省空间的方案。
表上只能有一个聚簇索引，所有其他索引都必须使用非聚簇索引。通过我的方法，我将对数据库的所有值进行聚簇索引。它将提高查询性能。
将索引放在物理数据中 - 这没有多大意义。索引性能的关键是每个索引都按排序顺序存储。如果它们只在物理布局中存储一次，那么你如何建议在任何可能的领域中做到这一点？最终，实际的行必须按某种方式排序（例如，在SQL Server中，这是聚簇索引）？
基本思想是，我们不是为每个列创建一个单独的表来进行有效访问，而是在物理层面上进行。
现在表格看起来像这样。
Row1 - OrderedHash（Column1），OrderedHash（Column2），OrderedHash（Column3）
答案 0 :(得分：1)
谷歌的“哈希索引”。例如，在SQL Server中，使用CHECKSUM函数创建并查询此索引。
当您需要索引包含长值的列时，这非常有用，例如： varchars，平均超过100个字符或类似的东西。
答案 1 :(得分：0)
如何为每个字段添加索引减少数据库的大小？除了哈希之外，您还必须存储所有真值;我们不只是想查询存在而是想要返回实际数据。
大多数RDBMS现在可以有效地回答大多数查询（特别是在使用关键索引的情况下）。我很难制定出数据库效率更高，节省空间的方案。
将索引放在物理数据中 - 这没有多大意义。索引性能的关键是每个索引都按排序顺序存储。如果它们只在物理布局中存储一次，那么你如何建议在任何可能的领域中做到这一点？最终，实际的行必须按某种方式排序（例如，在SQL Server中，这是聚簇索引）？
答案 2 :(得分：0)
我不认为你的方法非常有帮助。
与几乎每个数据库索引相比，哈希值仅对平等/不等式比较有帮助，但不低于/大于比较。
即使使用（in）相等哈希函数也不能提供100％保证给你正确的答案，因为哈希冲突可能发生，所以你仍然需要获取和比较原始值 - 繁荣，你只是失去了什么你想保存。
您可以让表中的行一次只能以一种方式排序。因此，如果您有一个应用程序，您必须在不同的查询中以不同方式排序行（例如，查询A需要按其名称排序的客户列表，查询B需要按其销售量排序的客户列表），其中一个查询将具有无序访问表。
如果您不希望数据库必须解决您不在查询中使用的列，那么使用带有额外数据列的索引 - 如果您的查询是根据该索引排序的，并且您的查询仅使用列在索引中（coulmns索引是基于您已明确添加到索引中的加号列），DBMS将不会读取原始表。
等