拆分规范化数据库表以快速访问？答案

【问题标题】：Splitting the normalized database table for fast access?拆分规范化数据库表以快速访问？
【发布时间】：2014-07-01 05:56:01
【问题描述】：

我在数据库中有一个规范化的表——比如说

(ID, name, age)

这里，每个条目对应一个人，ID是这个表的key。

非关键字段经常访问--通过名称字段搜索此表的频率足以满足一件事。

因此，我可以在名称字段上放置一个索引，因此该表也在该字段上建立了索引。

CTO 说这张表要分成 N 个表——每个表对应一个非关键字段（本例中 N=2）：

(ID, name)
(ID, age)

他建议这样做是为了快速访问查询。当这样分解时，这两个表中的每一个仍然将 ID 作为键，并且表未在其他字段上建立索引。

在我看来，这并不能提供快速访问——甚至会减慢速度：

没有索引意味着在查询中再次搜索整个表
一个额外的表访问，带来原始表的整行（姓名和年龄）而不是在找到匹配的行时在相应的行上获取它们。

这里缺少什么？

TIA

【问题讨论】：

你是对的。建议的解决方案没有任何好处。
thx - 如果您将其写为答案，我会接受。我相信这是一个完整的答案——正在寻找验证。
请注明您所指的数据库。也许它是某种类型的专有数据库，也许他对此有所了解，你我都不知道。我以前使用过专有数据库，它会在过滤之前读取整行。如果您谈论的是普通的现代 RDBMS，那么我建议您的 CTO 是一个小丑。
@Michael.M - 带有 Hibernate 的老式 MySQL，没有别的了。不确定我自己是否遗漏了什么——这很奇怪。
“这样分解，这两个表中的每一个仍然以ID为key，并且这些表没有在另一个字段上建立索引。” 逻辑是什么在不索引非键列的背后？

标签： sql database database-indexes

【解决方案1】：

您的推理是绝对正确的，建议的解决方案没有任何好处，甚至完全按照您描述的方式使事情变得更糟。

为经常搜索的字段添加索引会产生更好的结果，但根据搜索方法，实现的好处可能会受到限制。例如，搜索部分匹配 (name LIKE '%whatever%') 可能无法有效利用索引。

根据您使用的数据库，可能还有其他技术可以加快速度，例如内存缓存、全文索引等

【讨论】：

【解决方案2】：

简短的回答是，它总体上会降低性能并且是糟糕的设计。最重要的是，您应该维护外键约束，以便在需要时无法删除..（ID，名称）而不删除（ID，年龄）。这些 FK 约束将增加它们自己的开销。或者，您可能会选择不实施 FK，但随后您将数据集开放给不匹配记录的可能性。使用不会为您编写函数的常见 ORM 工具可以实现这种情况。另一方面，通过函数，您可以使用事务并确保两者一起通过或失败。对于写入来说也是如此。例如，如果 Mary Smith 结婚并且她的名字更改为 Mary White，该怎么办。最重要的是，我们需要改变她的年龄。现在，根据提议的设计，谨慎的做法是确保在一个数据库事务中更新两个表，这会增加复杂性

然后是 MySQL 维护的问题。在设计中添加比需要更多的表也会妨碍维护工作，并为 MySQL 自身的索引维护开销增加更多负载。

因此，除了降低数据库性能之外，由于增加了无用的复杂性，它还会降低开发人员的工作效率。

如果性能确实是个问题，并且您的数据集确实那么大，并且您确实需要快速文本查找等，那么更好且广泛使用的技术将是使用像 Sphinx 这样的技术。

老实说，听起来他可能读过一些关于分片的东西，并且完全误解了他所读的内容。

【讨论】：