为什么 Wordpress 有单独的“usersmeta”和“users”SQL 表。为什么不把它们结合起来呢？

除了 users 表之外，Wordpress 还有一个 usersmeta 表，其中包含以下列

• meta_id
• user_id
• 元键（例如名字）
• 元值（例如汤姆）

每个用户在 usersmeta 表中都有 20 行，无论这些行是否有填充的 meta_value。也就是说，将始终存在的元行添加到用户表中不是更有效吗？

我猜测 users 表中的信息被更频繁地查询（例如 user_id、username、pass），因此保持这些行较小会更有效。这是真的？这种表分离还有其他原因吗？

实体属性值

它被称为实体属性值 http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model(EAV) 数据模型，并允许将任意数量的属性分配给给定实体。这意味着每个用户可以有任意数量的元数据条目。

为什么使用它

默认情况下，wordpress 设置了几个键（问题中提到了 20 个），但可以有任意数量。如果所有用户都有一千个元数据条目 - 每个用户的 usermeta 表中只有一千个条目 - 它对用户可以拥有的元数据条目的数量没有限制（就数据库结构而言） 。它还允许一个用户拥有 1000 个元数据整体，而所有其他用户拥有 20 个并且仍然有效地存储数据 - 或其任何排列。

除了灵活性之外，使用这种结构还可以使主用户表保持较小，这意味着查询更加高效。

备择方案

使用 EAV 的替代方案包括：

• 每当属性数量发生变化时修改架构
• 将所有属性存储在序列化字符串中（在用户对象上）
• 使用无模式数据库

权限是第一点的最大问题，授予全面访问权限来更改数据库表的架构并不是一个好主意，并且对于许多（如果不是大多数）wordpress 安装（托管在 wordpress.com 或在 db 用户没有更改权限的共享主机上）。 Mysql也有一个硬限制4096 列和每行 65,535 字节 http://dev.mysql.com/doc/refman/5.6/en/column-count-limit.html。尝试在单个表中存储大量列最终会失败，并在此过程中创建一个查询效率低下的表。

将所有属性存储在序列化字符串中将使元数据值查询变得困难且缓慢。

Wordpress 与 mysql 紧密相关，因此更改数据存储并不是一个现实的选择。

更多 WP 信息

如果您没有使用任何/许多插件，则每个用户的 usermeta 表中的行数可能是恒定的，但通常您添加的每个插件可能需要为用户添加元数据；添加的数字可能不是微不足道的，并且该数据存储在 usermeta 表中。

的文档添加元用户 http://codex.wordpress.org/Function_Reference/add_user_meta可能会更清楚地说明为什么数据库是这样构造的。如果你把这样的代码放在某处：

add_user_meta($user_id, "favorite_color", "blue");

它将在 usermeta 表中为给定的 user_id 创建一行，而不需要向主用户表添加列 (favorite_color)。这使得通过最喜欢的颜色查找用户变得很容易，而无需修改用户表的架构。