mysql–元表VS表有很多字段,大规模.性能方面

这是一个具体的例子：

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

但是,仅在50个左右的用户之后,该表已经包含了大约1219条记录.

所以,我的问题是：在大规模,性能方面,最好是将一个包含所有meta作为字段的表,或者像WordPress这样的表将所有元作为一行？

在两种情况下都正确设置了索引.几乎没有必要添加新的元素.请记住,像wp_usermeta这样的表必须使用text / longtext字段类型(大脚印)才能容纳可输入的任何类型的数据.

我的假设是,当您不知道用户可能需要什么时,WordPress方法才有用.除此以外：

>检索所有元数据需要更多I / O,因为这些字段不存储在单行中.该字段未优化.
>你不能真正拥有meta_value字段的索引而不会遇到重大缺点(索引一个longtext？除非它是一个部分索引……但是,那么,多长时间？)
>很快,你的数据库就会堆满许多行,即使对于最精确的元数据也会诅咒你的研究
>缺乏开发人员.您无法真正执行加入请求以获取所需的所有内容并正确显示.

我可能会错过一点.我不是数据库工程师,我只知道SQL的基础知识.

解决方法:

你在谈论实体 – 属性 – 价值.

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


这样的模式非常适合于为任何给定的实体允许动态数量的属性.您无需更改架构即可添加属性.根据查询,通常可以使用新属性而无需更改任何SQL.

只要您知道要查找的实体和属性,它在检索这些属性值方面也非常快.它只是一个很棒的Key-Value-Pair类型的设置.

但是,如果您需要根据Value内容搜索记录,则不太好.比如,让我所有用户称为’John Smith’.用英语问小事.对“正常”表格进行编码是微不足道的; first_name =’John’和last_name =’Smith’.但是在针对EAV的SQL中编写非常简单,并且可怕的相对性能; (得到所有的约翰斯,然后是所有的史密斯,然后将它们相交以获得与两者相匹配的实体.)

关于EAV的在线有很多说法,所以我不会在这里详细介绍.但一般的经验法则是：如果你可以避免它,你可能应该这样做.