WordPress 数据库的终极指南
已发表: 2022-02-09WordPress 的核心是一个 CMS（内容管理系统）。 要管理内容，它需要能够存储它。 WordPress 通过文件夹和文件以及数据库来做到这一点。 我们之前在另一篇文章中介绍了 WordPress 文件系统； 这次我们将专注于数据库。
在本文中，我们将研究 WordPress 数据库、它的结构以及每个字段的工作方式。 我们还包括一个关于 MySQL 的简短历史课程。 提示——MySQL 中的 My 并不意味着它是你的； 我是一个真实的人，但谁？ - 继续阅读以找出答案。
目录
- SQL、MySQL 和 MariaDB 的（非常）简史
- 如何访问 WordPress 数据库
- phpMyAdmin
- Plesk/cPanel
- SSH/MySQL/MariaDB 客户端
- WordPress 插件
- WordPress数据库结构
- 表结构
- wp_commentmeta
- wp_comments
- wp_links
- wp_options
- wp_postmeta
- wp_posts
- wp_terms
- wp_termmeta
- wp_term_relationships
- wp_term_taxonomy
- wp_usermeta
- wp_users
- 表结构
SQL、MySQL 和 MariaDB 的（非常）简史
WordPress 使用称为 MySQL 的 RDBMS。 从技术上讲，它是基于 MySQL 的，因为越来越多地使用 MariaDB 代替 MySQL。 SQL 代表结构化查询语言，是我们用来与数据库交互的语言，而不是数据库本身。
正如我们今天所知，MySQL 在互联网的发展中发挥了重要作用。 它于 1995 年首次推出，作为 Microsoft 和 Oracle 提供的产品的替代品，很快成为首选的黄金 RDBMS 标准。
MySQL 的历史是丰富多彩的，先后被 Sun Microsystems 和 Oracle 收购（Oracle 收购了 Sun Microsystems 和 MySQL）。
作为对甲骨文收购 MySQL 的回应，MySQL 的创始人 Monty Widenius 将 MySQL 分叉成 MariaDB，并以他的女儿 Maria 的名字命名。 （有趣的是，MySQL 是以蒙蒂的另一个女儿命名的——我的）。 随着时间的推移，MariaDB 和 MySQL 之间的差异越来越大； 但是，这两者在许多情况下仍然可以互换，包括 WordPress 数据库。
事实上，在许多情况下，MariaDB 被认为是 MySQL 的替代品。 这意味着您可以卸载 MySQL，安装 MariaDB，然后继续工作，就好像没有任何改变一样。 话虽如此，MariaDB 可以在某些情况下提供性能改进，并提供与存储引擎等更广泛的兼容性。
重要的是要注意 MySQL 仍然是免费的，并且是在双许可系统下发布的。 在许多情况下，MySQL 用于指代 MySQL 或 MariaDB 的数据库。
如何访问 WordPress 数据库
在连接到 WordPress 数据库时，有几个不同的选项可用。 您可以使用的一种或多种方法在很大程度上取决于您使用的 WordPress 托管类型。 如果您不确定您的服务器是如何配置的，请咨询您的托管服务提供商或系统管理员。 无论哪种方式，选项都可以包括；
phpMyAdmin
phpMyAdmin 是一个最受欢迎的工具，因为它允许我们通过基于 Web 的 GUI 连接到数据库。 phpMyAdmin 需要安装在托管数据库的同一台服务器上，许多托管服务提供商直接提供 phpMyAdmin。
Plesk/cPanel
Plesk 和 cPanel 是两个提供类似功能的控制面板平台——便于服务器管理的用户界面。 当然，存在某些关键差异，包括它们支持的技术和操作系统。 无论哪种方式，它们也允许我们访问数据库，尽管方式略有不同。
SSH/MySQL/mariaDB 客户端
SSH 是一种用户友好度较低的数据库连接方式，它提供 CLI（命令行界面）而不是 GUI。 因此，建议对 SQL 命令有更深入的了解。 在连接到数据库之前，需要在托管数据库的同一台服务器上显式设置 SSH。
插件
您还可以使用 WordPress 插件来访问您的 WordPress 数据库。 使用插件，您可以直接从 WordPress 管理控制台访问数据库。 在这里，您需要确保从信誉良好的供应商处选择插件，并遵循所有适用的最佳实践来确保您的数据安全。 如果您不确定要使用哪个插件，请阅读我们的指南，了解如何为您的 WordPress 网站选择最佳插件。
WordPress数据库结构
WordPress 数据库由 12 个表组成。 默认情况下，每个表都以 wp_ 前缀开头； 但是，这可以在初始安装和配置过程中更改。 出于 WordPress 安全原因，通常建议更改前缀，特别是如果您打算或已经在同一台服务器上进行了多个安装。
组成 WordPress 数据库的 12 个表如下（按字母顺序列出）：
- wp_commentmeta
- wp_comments
- wp_links
- wp_options
- wp_postmeta
- wp_posts
- wp_terms
- wp_termmeta
- wp_term_relationships
- wp_term_taxonomy
- wp_usermeta
- wp_users
我们现在将逐个浏览每个表并查看它存储的数据及其内部结构。
表结构
在我们深入了解每个表的细节之前，有必要花一些时间来了解一下它的结构。 如果您不熟悉数据库文档，本节将为您提供速成课程，您会在下一节中找到有用的。 另一方面，如果您对 SQL 表非常熟悉，请随意跳过。
- 字段名称 - 这是字段的名称，您可以在 SQL 表中找到该名称
- 描述 - 我们将其放入以帮助您了解该字段包含哪些类型的数据
- 类型 – 这是字段接受的数据类型。 括号中的数字表示我们可以输入的可接受字符数量的硬性限制
- Null - 目前尚不清楚为什么使用此字段
- 键 - 这告诉我们条目是否是键。 有不同类型的键，包括：
- 基本的
- 主要（部分）
- 指数
- 索引（部分）
- 独特
- 多
- 默认 - 如果条目有默认值，默认值将在此处列出
- 注释 - 任何附加注释
wp_commentmeta
wp_commentsmeta 表存储与评论相关的元数据。 评论单独存储在 wp_comments 表中。 该表具有以下字段：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| meta_id | 这是条目的唯一 ID。 它会自动递增 | bigint(20) 无符号 | 基本的 | ||
| comment_id | 这是在 wp_comments 表中找到的与元数据相关的评论的 ID | bigint(20) 无符号 | 指数 | 0 | |
| 元密钥 | 这标识条目用于的元数据类型 | varchar(255) | 是的 | 指数 | 空值 |
| 元值 | 这是实际的元数据 | 长文本 | 是的 | 空值 |
wp_comments
wp_comments 表存储帖子评论。 与评论相关的元数据存储在 wp_commentmeta 表中。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| 评论 ID | 这是条目的唯一 ID。 它会自动递增 | 大整数（20） | 基本的 | 不适用 | |
| comment_post_ID | 这是写评论的帖子的 ID，可在 wp_posts 表中找到 | 大整数（20） | 指数 | 0 | |
| 评论作者 | 这是写评论的作者的名字 | 小文本 | |||
| comment_author_email | 这是撰写评论的作者的电子邮件地址 | varchar(100) | 指数 | ||
| 评论作者网址 | 这是写评论的作者的网址 | varchar(200) | |||
| comment_author_IP | 这是写评论的作者的IP地址 | varchar(100) | |||
| 评论日期 | 这是发表评论的日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| comment_date_gmt | 这是发表评论的 GMT（格林威治子午线时间）日期和时间 | 约会时间 | 索引和索引 Pt2 | 0000-00-00 00:00:00 | |
| 评论内容 | 这是留下的实际评论 | 文本 | |||
| 评论业力 | 这可供插件用于评论管理目的 | 整数（11） | |||
| 评论批准 | 这表明评论是否已被批准 | varchar(20) | 索引第 1 部分 | 0 | |
| 评论代理 | 这是发表评论的地方 | varchar(255) | |||
| 评论类型 | 这是留下的评论类型 | varchar(20) | |||
| 评论父 | 如果评论是回复，则该字段表示父评论 | bigint(20) 无符号 | 指数 | 0 | |
| 用户身份 | 如果注册了评论用户，这将是他们在 wp_users 中可用的 ID | bigint(20) 无符号 | 0 |
wp_links
该表最初是为了支持 blogrolls 而创建的，该功能从 WordPress 3.5 开始就被删除了。 保留它是为了向后兼容，但不再使用。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| 链接ID | 这是条目的唯一 ID。 自动递增 | bigint (20) 无符号 | 基本的 | ||
| 链接网址 | 这是链接的网址 | varchar(255) | |||
| 链接名称 | |||||
| 这是链接的名称 | varchar(255) | ||||
| 链接图像 | 这是链接相关图片的 URL | varchar(255) | |||
| 链接目标 | 这是链接的目标框架 | varchar(25) | |||
| 链接描述 | 这是链接的描述 | varchar(255) | |||
| 链接可见 | 这告诉我们链接是否公开显示 | varchar(20) | 指数 | 是 | |
| 链接所有者 | 这是在 wp_users 中创建链接的用户的用户 ID | bigint (20) 无符号 | 1 | ||
| 链接评级 | 这是链接的评分 | 整数（11） | 0 | ||
| 链接更新 | 这是链接更新的日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| 链接关系 | 这是链接的关系 | varchar(255) | |||
| 链接笔记 | 这是关于链接的注释 | 中文本 | |||
| 链接RSS | 这是链接的 rss 提要地址 | varchar(255) |
wp_options
通过管理控制台配置的 WordPress 设置存储在这里。 插件和主题通常还会在此处存储设置信息，如下面的屏幕截图所示。 在这里，我们可以看到我们自己的网站文件更改监视器的扫描频率选项设置为每天。 
该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| option_id | 这是条目的唯一 ID。 自动递增。 | bigint(20) 无符号 | 基本的 | ||
| 选项名称 | 这是选项/设置的名称 | varchar(64) | 独特 | ||
| 选项值 | 这是正在存储的设置值 | 长文本 | |||
| 自动加载 | 此设置告诉 wp_load_alloptions() 是否应该自动加载选项 | varchar(20) | 指数 | 是的 |
wp_postmeta
每个帖子附带的帖子元数据存储在这里。 元数据可以包括附加文件、缩略图、所需的帖子标签和其他此类信息。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| meta_id | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| 字段名称 post_id | 这是与元数据相关联的帖子的 ID，在 wp_posts 中可用 | bigint(20) 无符号 | 指数 | 0 | |
| 元密钥 | 这是一个标识元数据的索引键，因为每个帖子可以有多个元数据 | varchar(255) | 是的 | 指数 | 空值 |
| 元值 | 这是实际的元数据 | 长文本 | 是的 | 空值 |
wp_posts
wp_posts 表是一个主要的表，包含 WordPress 数据的核心。 它包含实际的帖子、页面以及导航菜单项，如下面的示例所示，该示例显示了每个 WordPress 全新安装中包含的默认示例页面。 
该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| ID | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 主要和索引（第 4 部分） | ||
| post_author | 这是写这篇文章的作者的 ID，在 wp_users 中可用 | bigint(20) 无符号 | 指数 | 0 | |
| 发布日期 | 这是创建帖子的日期和时间 | 约会时间 | 索引（第 3 部分） | 0000-00-00 00:00:00 | |
| post_date_gmt | 这是创建帖子时的 GMT（格林威治标准时间）日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| post_content | 这是帖子的实际内容 | 长文本 | |||
| 帖子标题 | 这是帖子的标题 | 文本 | |||
| post_excerpt | 这是帖子的摘录 | 文本 | |||
| post_status | 这是帖子的状态 | varchar(20) | 索引（第 2 部分） | 发布 | |
| 评论状态 | 这告诉我们是否允许对帖子发表评论 | varchar(20) | 打开 | ||
| ping_status | 这告诉我们是否允许 ping 和 trackbacks | varchar(20) | 打开 | ||
| post_password | 帖子可以使用此处存储的任何适用密码进行密码保护 | varchar(20) | |||
| post_name | 这是帖子标题的 URL slug | varchar(200) | 指数 | ||
| to_ping | 这是 WordPress 在帖子更新时应向其发送 pingback 的 URL 列表 | 文本 | |||
| ping 通 | 这是 WordPress 在更新时 pingback 的 URL 列表 | 文本 | |||
| post_modified | 这是帖子最后修改的日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| post_modified_gmt | 这是帖子最后修改的 GMT 日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| post_content_filtered | 这是 post_content 的过滤版本，通常由插件用于缓存目的 | 长文本 | |||
| post_parent | 当 post 是修订或附件时，这将创建父子关系 | bigint(20) 无符号 | 指数 | 0 | |
| 向导 | 这是帖子的全局唯一标识符 (GUID) | varchar(255) | |||
| 菜单顺序 | 这是页面和非发布项目出现的订单号 | 整数（11） | 0 | ||
| post_type | 这标识了内容类型 | varchar(20) | 索引（第 1 部分） | 邮政 | |
| post_mime_type | 这是帖子附件的 MIME 类型 | varchar(100) | |||
| 评论计数 | 这是评论、引用和 pingback 的总数 | 大整数（20） | 0 |
wp_terms
术语是用于对 WordPress 中的对象进行分类的分类对象。 例如，帖子中使用的类别和标签是术语的类型。 此表包含整个 WordPress 中使用的所有不同类型的术语。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| term_id | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| 姓名 | 这是术语的名称 | varchar(200) | 指数 | ||
| 蛞蝓 | 这是术语的蛞蝓 | varchar(200) | 多 | ||
| 术语组 | 这是主题和插件可以用来将术语组合在一起的别名 | 大整数（10） | 0 |
wp_termmeta
此表存储与 wp_terms 中的术语相关联的元数据。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| meta_id | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| term_id | 这是 wp_terms 中可用的元数据相关术语的 ID | bigint(20) 无符号 | 指数 | 0 | |
| 元密钥 | 这是术语元数据的标识符键 | varchar(255) | 是的 | 指数 | 空值 |
| 元值 | 这是实际的元数据 | 长文本 | 是的 | 空值 |
wp_term_relationships
此表维护帖子和分类法之间的关系。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| object_id | 这是 wp_posts 中可用的帖子 ID | bigint(20) 无符号 | 初级（第 1 部分） | 0 | |
| term_taxonomy_id | 这是 wp_term_taxonomy 中可用的术语分类的 ID | bigint(20) 无符号 | 主要（第 2 部分）和索引 | 0 | |
| term_order | 这是术语的顺序 | 整数（11） | 0 |
wp_term_taxonomy
该表提供了术语分类法，因此，它们提供了可以使用的上下文。 例如，我们可以将术语数据库用作帖子类别和产品类别（假设我们正在销售数据库服务）。 在这种情况下，帖子类别和产品类别是术语分类法。 该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| term_taxonomy_id | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| term_id | 这是 wp_terms 中可用的术语的 ID | bigint(20) 无符号 | 独特的（第 1 部分） | 0 | |
| 分类 | 这是分类学的蛞蝓 | varchar(32) | 唯一（第 2 部分）和索引 | ||
| 描述 | 这是分类的描述 | 长文本 | |||
| 父母 | 如果分类是子分类，这是父分类的 ID | bigint(20) 无符号 | 0 | ||
| 数数 | 这是分配此分类的对象数 | 大整数（20） | 0 |
wp_usermeta
此表存储 wp_users 表中未找到的其他用户数据。 WordPress 本身以及插件或主题都可以使用此表。
用户元数据的一个示例是用户昵称。 虽然 WordPress 默认包含此字段，但它仍然是元数据的一部分，如下所示。 另一个例子是 WooCommerce； 使用此表存储客户信息（例如送货地址）的电子商务插件。
该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| umeta_id | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| 用户身份 | 这是与 wp_users 中的信息相关的用户 ID | bigint(20) 无符号 | 指数 | 0 | |
| 元密钥 | 这是元条目的关键标识符 | varchar(255) | 是的 | 指数 | 空值 |
| 元值 | 这是实际的元数据 | 长文本 | 是的 | 空值 |
wp_users
WordPress 用户的信息存储在这里。 由于用户是 WordPress 生态系统不可或缺的一部分，因此此表是必不可少的。
该表仅存储每个用户的核心信息，如下例所示。 所有其他信息都存储在 wp_usermeta 表中。
该表具有以下列：
| 列名 | 描述 | 类型 | 空值 | 钥匙 | 默认 |
|---|---|---|---|---|---|
| ID | 这是条目的唯一 ID。 自动递增 | bigint(20) 无符号 | 基本的 | ||
| 用户登录 | 这是用户的用户名 | varchar(60) | 指数 | ||
| 用户通行证 | 这是用户的密码 | varchar(64) | |||
| user_nicename | 这是用户的显示名称 | varchar(50) | 指数 | ||
| 用户电子邮件 | 这是用户的电子邮件地址 | varchar(100) | |||
| 用户网址 | 这是用户的 URL（例如网站） | varchar(100) | |||
| 用户注册 | 这是用户注册的日期和时间 | 约会时间 | 0000-00-00 00:00:00 | ||
| user_activation_key | 这是用户的激活密钥，用于重置密码 | varchar(60) | |||
| 用户状态 | 这不再从 WordPress 3.0 开始使用，而是用于指示用户是否是垃圾邮件 | 整数（11） | 0 | ||
| 显示名称 | 这是用户的公开显示名称 | varchar(250) |
熟悉 WordPress 数据库
数据库对于外行来说可能非常令人生畏——毕竟，它们保存了 WordPress 工作所需的所有数据。 虽然这里的失误确实会导致网站崩溃，但不要让这吓倒你。 毕竟，如果需要，了解 WordPress 数据库的方式可以大大简化您的故障排除工作。
设置测试或登台环境可以为您提供一个安全的空间，您可以在其中自由地进行试验，而不会冒着使您的网站脱机的风险。 您甚至可以在您的计算机上免费设置 XAMPP 暂存环境——为您提供掌握 WordPress 数据库所需的一切。