是拥有更多的列更好，还是拥有更多的表更好？

Question

想象一个假设的数据库，它存储产品。每个产品都有 100 个属性，但任何给定的产品只会为其中大约 50 个属性设置值。我可以看到三种存储这些数据的方法：

1. 一个有 100 列的表，

2. 一个表的内容很少（比如每个产品都有一个值的 10 列），另一个表包含列（product_id、属性、值）。即，EAV 数据存储。

3. 每列都有一个单独的表。因此，核心产品表可能有 2 列，并且还有 98 个其他表，每个表都有两列 (product_id, value)。

抛开这些极端之间的灰色阴影，从纯粹效率的角度来看，哪个最好使用？我认为这取决于正在运行的查询的类型，即大多数查询是针对产品的多个属性，还是针对多个产品的单个属性的值。这对效率有何影响？

假设这是一个使用 InnoDB 的 MySQL 数据库，并且所有表都有适当的外键以及 Product_id 上的索引。假设属性名称和值是字符串，并且没有索引。

一般来说，我问访问一个非常大的表是否比具有许多连接的查询花费更多或更少的时间。

我在这里发现了类似的问题：最好有数百列或分成多个表？

不同之处在于，该问题是针对特定情况询问的，并没有真正告诉我一般情况下的效率。其他类似的问题都是在讨论组织数据的最佳方式，我只是想知道不同的组织系统如何影响查询的速度。

Answer 1

一般来说，我问访问一个非常大的表是否比具有许多连接的查询花费更多或更少的时间。

JOIN会比较慢。

但是，如果您通常只查询列的特定子集，并且该子集被“垂直分区”到其自己的单独表中，则查询此类“精简”表通常比查询包含所有列的“胖”表更快。

但这是非常具体和脆弱的（随着系统的发展很容易分解）情况，您应该在走这条路之前非常仔细地测试。您的默认起始位置应该是一张桌子。