mysql - 元表 VS 字段多、规模大的表。性能方面

Question

这是一个具体的例子:

Wordpress 将用户信息(meta)存储在一个名为 wp_usermeta 的表中，您可以在其中获取 meta_key 字段(例如:first_name)和 meta_value (John)

然而，仅仅在 50 个左右的用户之后，该表就已经包含了大约 1219 条记录。

所以，我的问题是:在大规模、性能方面，拥有一个将所有元​​数据作为字段的表更好，还是像 WordPress 那样将所有元数据作为一行的表更好？

在这两种情况下都正确设置了索引。几乎不需要添加新元数据。请记住，像 wp_usermeta 这样的表必须使用文本/长文本字段类型(占用空间大)才能容纳可以输入的任何类型的数据。

我的假设是，只有当您不知道用户可能需要什么时，WordPress 方法才有用。否则:

• 检索所有元数据需要更多的 I/O，因为字段不是存储在一行中。该字段未优化。
• 如果没有重大缺陷(索引长文本？除非它是部分索引......但是，多长时间？)，你不可能真正在 meta_value 字段上建立索引。
• 很快，您的数据库就会塞满许多行，即使是最精确的元数据也会对您的研究不利
• 缺少对开发人员友好的功能。您实际上无法通过加入请求来获得所需的一切并正确显示。

不过我可能漏掉了一点。我不是数据库工程师，我只知道 SQL 的基础知识。

Answer 1

你说的是实体属性值。

- Entity    = User, in your Wordpress Example  
- Attribute = 'First Name', 'Last Name', etc  
- Value     = 'John', 'Smith', etc  

这样的模式非常擅长为任何给定的实体允许动态数量的属性。您无需更改架构即可添加属性。根据查询的不同，通常无需更改任何 SQL 即可使用新属性。

如果您知道要查找的实体和属性，那么检索这些属性值的速度也非常快。这只是一个非常奇特的键值对类型的设置。

但是，如果您需要根据 Value 内容搜索记录，则不太好。例如，获取所有名为“John Smith”的用户。用英语问很简单。针对“普通”表进行编码很简单； first_name = 'John' AND last_name = 'Smith'。但是针对 EAV 编写 SQL 并不简单，而且相对性能也很糟糕； (获取所有 Johns，然后获取所有 Smiths，然后将它们相交以获得与两者匹配的实体。)

网上关于EAV的说法很多，这里就不赘述了。但一般的经验法则是:如果你能避免它，你可能应该避免。