Database 数据库优化：散列所有值

通常，数据库的设计如下，以允许实体具有多种类型

实体名称 类型 附加信息

例如，实体名称可以类似于账号，类型可以类似于银行数据库中的储蓄、活期等

大多数情况下，类型将是某种字符串。可能存在与实体类型关联的其他信息

通常情况下，查询将这样提出。 是否查找此特定类型的帐号？ 查找余额大于100万的X类账号

要回答这些查询，如果索引与特定列关联，查询分析器将扫描索引。否则，它将对所有行进行完全扫描

我正在考虑下面的优化。 为什么不将每列数据的哈希值或整数值存储在实际表中，以便维护排序属性，以便进行比较

它有以下优点。 1.表的大小将大大减少，因为我们将为每个列数据存储较小的值。 2.我们可以为每列的哈希值构造一个聚集的B+树索引，以检索匹配或大于或小于某个值的对应行。 3.通过在主存中使用B+树索引并检索相应的值，可以轻松检索相应的值。 4.不经常出现的值永远不需要检索

我仍然有更多的优化在我的脑海中。我将根据对这个问题的反馈发布这些信息

我不确定这是否已经在数据库中实现，这只是一个想法

谢谢你阅读这篇文章

--巴拉

更新：

我不想模仿数据库的功能。通常索引是由数据库管理员创建的。我试图通过在数据库中的所有字段上建立索引来提出一个物理模式，这样可以减少数据库表的大小，并且很容易回答一些查询

更新：（乔的回答）

---

向每个字段添加索引如何减少数据库的大小？除了散列，您还必须存储所有真值；我们不仅要查询是否存在，还要返回实际数据

在典型的表中，所有物理数据都将被存储。但现在，通过对每列数据生成一个哈希值，我只将哈希值存储在实际表中。我同意这不是减少数据库的大小，而是减少表的大小。当您不需要返回所有列值时，它将非常有用

大多数RDBMS现在能够高效地回答大多数查询（特别是在关键索引就绪的情况下）。我很难制定这样的场景：您的数据库将更加高效并节省空间

一个表上只能有一个聚集索引，所有其他索引都必须是非聚集索引。使用我的方法，我将对数据库的所有值进行聚集索引。它将提高查询性能

将索引放在物理数据中——这真的没有意义。索引性能的关键在于每个索引都是按排序顺序存储的。如果它们在物理布局中只存储一次，您建议如何跨任何可能的字段执行此操作？最终，实际的行必须按某种方式排序（例如，在SQL Server中，这是聚集索引）

其基本思想是，我们不是为每一列创建一个单独的表以实现高效访问，而是在物理级别上进行

现在这张桌子看起来像这样

---

行1-OrderedHash（第1列）、OrderedHash（第2列）、OrderedHash（第3列）

向每个字段添加索引如何减少数据库的大小？除了散列，您还必须存储所有真值；我们不仅要查询是否存在，还要返回实际数据

大多数RDBMS现在能够高效地回答大多数查询（特别是在关键索引就绪的情况下）。我很难制定这样的场景：您的数据库将更加高效并节省空间

---

将索引放在物理数据中——这真的没有意义。索引性能的关键在于每个索引都是按排序顺序存储的。如果它们在物理布局中只存储一次，您建议如何跨任何可能的字段执行此操作？最终，实际的行必须按某种方式排序（例如，在SQL Server中，这是聚集索引）

我认为您的方法没有多大帮助

散列值仅对相等/不相等比较有帮助，但与几乎所有数据库索引相比，不小于/大于比较

即使使用（in）equality散列函数，也不能100%保证给出正确答案，因为散列冲突可能会发生，因此您仍然需要获取并比较原始值-boom，您刚刚丢失了想要保存的内容

表中的行一次只能按一种方式排序。因此，如果您有一个应用程序，您必须在不同的查询中对行进行不同的排序（例如，查询A需要按姓名排序的客户列表，查询B需要按销售额排序的客户列表），其中一个查询必须无序访问表

如果您不希望数据库必须处理查询中不使用的列，则使用具有额外数据列的索引-如果您的查询是根据该索引排序的，并且您的查询只使用索引中的列（索引基于您显式添加到索引中的加列），DBMS不会读取原始表

等等。

谷歌搜索“散列索引”。例如，在SQL Server中，这样的索引是使用校验和函数创建和查询的

当您需要为包含长值的列编制索引时，这一点非常有用，例如，varchar平均值超过100