如果一个表中有很多未使用/未选择的列，会影响性能吗？

Question

如果一个表中有很多未使用/未选择的列，会影响性能吗？

3

背景： 我有一个名为“cars”的表格，存储了大量的二手汽车，约100万行。该表格有超过170个列。该表格以单个列为索引。其中大多数列是布尔类型（例如，“是否具有自动变速箱”等），其余的是字符串和数字（例如颜色和价格）。汽车显示在一个视图中，我在其中使用了总共170个中的80个左右。

我的问题： 所以我的问题是，在执行搜索时，如果我只选择了表格中的80个列，还是另一方面，我只制作一个仅由我需要的这80个列而不是全部170个列组成的新表格，这是否会影响性能？换句话说，表格包含未被选定的列是否会影响性能？

- Niels Kristian

1

与大多数性能问题一样，答案是“取决于情况”。为什么不对您提出的两个解决方案进行基准测试呢？ - Andomar

2

测试生产环境确实比较复杂。这取决于什么？如果你有正确的知识，这应该是一个相当容易回答的问题，因为除了未使用的列数，所有因素都是恒定的。 - Niels Kristian

2

一张表本身从来不会是“慢”或“快”的——查询才会。获取所有170列的查询肯定比只获取其中80列的查询要慢。 - user330315

1

PostGre 通过一次从磁盘读取“页面”数据来读取表行。行大小越大，每个页面可以存储的行数就越少。如果两个表的页面大小相同，则针对较小表的查询需要更少的页面读取才能获取要返回的行数据（即每个具有200行的表需要20次页面读取，而每个具有400行的表需要10次页面读取），因此可能会在速度上获得微小的改进。这种改进可能非常小，以至于被其他因素所掩盖，例如并发磁盘访问，缓存命中等。 - paul

2

请注意，对单个布尔列进行索引不太可能带来性能上的好处。索引在帮助您快速到达某行时表现良好。如果索引中一半的值为真，一半为假，则该索引几乎没有用处。如果90％为真（10％为假），那么它可能有助于更快地找到带有假值的行，但它对真值行无任何作用；忽略索引并进行表扫描会更快（几乎必然）。索引应具有较好的选择性；应有许多不同的关键字值（两个不是“很多”）。 - Jonathan Leffler

显示剩余8条评论

3个回答

2

此外，您可能想阅读dba.SE上类似问题的答案:

Do the number of columns in a particular table affect the performance
of a query, when querying on a subset of that table?

简而言之：是的，它确实会读取未选择的列，因为这些未选择的列通常与所选列位于同一磁盘块中，因此无论如何都会被读取。

- Daniel Vérité

0

你的100万辆汽车大部分属性可能都依赖于某些隐藏的因素，例如{品牌、型号、制造商、型号版本}。你可以将这些属性提取到一个单独的表格中，并在主要的汽车表格中引用该表格。在最终情况下，你的主要汽车表只包含属于特定汽车模型实例的属性（例如：{编号、价格、建造日期、购买日期、（可能）颜色}）。

- wildplasser

谢谢，如果您愿意，请尝试这个问题：http://stackoverflow.com/questions/8345015/rails-activerecord-and-db-normalization - Niels Kristian

抱歉，我无法阅读那个。对我来说，这都是胡言乱语。（在我看来，它的语义也没有明确定义） - wildplasser

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Adam Robinson · Accepted Answer

Andomar在他的评论中是正确的，“这取决于”(it depends)。然而，如果你提出的问题是这样的：

“表中的列数是否会影响选择查询？”

那么答案是是。它们是“extra”或“unused”与数据库设计有关，与性能无关。

其他所有条件相同的情况下，具有100列的表中的一行将占用比具有10列的表中的一行更多的空间。因为行更大，相对地，你的服务器要在更宽的表中遍历相等数量的行，比在小表中遍历更多行，所以服务器会相对较努力。

在行的大小占用更多空间的表中，也会更频繁地发生页面分裂等现象。

如果你的问题是（我认为这更符合你的疑问）：

“假设所有条件都相同，则从具有170列的表中选择80列的查询是否比从具有80列的表中选择80列的查询慢?”

那么答案应该是否。