当客户报告管理员界面缓慢、结账失败或随机超时等问题时，机构没有时间逐一梳理数十个数据表或逆向分析插件行为。你需要快速识别可能的故障点，并将注意力集中在关键之处。
在实践中，大多数严重的性能和稳定性问题都可以追溯到少数几个随时间不断增长的数据库表。这些表在新站点或低流量网站上不会造成问题，但随着多年内容、插件和用户活动的积累，它们却是导致崩溃、慢查询和紧急支持工单的主要原因。
本文重点介绍五个 WordPress 数据库表（和表模式），因为随着站点规模增长，这些是维护机构最需要密切关注的对象，也是最可能导致实际性能问题的因素。
为什么机构只需要关注 20% 的数据库
帕累托法则 有助于解释许多运营模式，同样也适用于 WordPress 数据库维护。机构遇到的问题并非均匀分布在整个数据库中。相反，一小部分表占用了大部分与数据库相关的性能下降、崩溃和紧急支持工单。
标准 WordPress 安装会创建12个默认表。其中一些表（如 wp_users、wp_links 和分类表）可以正常运行多年而不会引发问题。这些表通常不会触发流量高峰期导致站点崩溃的慢查询。
然而，高风险表有一个共同特点：它们可以在大规模时导致站点崩溃。拥有 100 篇文章的站点可能无限版本运行良好。但同样一个站点，如果拥有 10,000 篇文章和 300,000 条修订版本记录，很可能在每个编辑界面上都超时。拥有 50 个产品的电商商店应该运行良好，但扩展到 5,000 个产品可能导致页面加载需要数秒。
导致 WordPress 站点在大规模时失败的五种数据库模式
让我们回顾一下在机构维护工作中经常出现的五种模式。
它们在小站点上不会立即造成危险，但随着内容、流量和插件活动的增加，它们成为慢查询、超时和稳定性问题的最常见来源。
wp_options：自动加载膨胀可能导致高流量站点崩溃
wp_options 表 存储站点设置和插件配置，并决定 WordPress 在每个页面请求（包括缓存页面）时加载哪些选项。在各列中，autoload（自动加载） 最为重要：
WordPress 首先在每个请求时将所有自动加载的选项加载到内存中。自动加载数据较少的站点可以正常处理流量，但随着自动加载数据增长，每个访问者消耗的内存会比服务器为每个 PHP 进程分配的内存更多。
如果自动加载数据过大（比如超过约 3MB 或更大），你就会看到管理员界面缓慢、销售期间结账失败，以及 502 错误。
罪魁祸首几乎总是孤立的插件设置或称为瞬态的临时缓存条目。启用自动加载后，你删除的一些插件选项可能会保留在 wp_options 表中，这意味着它们在每个请求时都会被加载。经过数月或数年、数十个插件的积累，这些废弃数据会在每个页面视图中加载。
上面的 Database Studio 中的 SQL 控制台可让您运行查询来检查自动加载数据的大小（以字节为单位）：
SELECT 'autoloaded data in KiB' as name, ROUND(SUM(LENGTH(option_value))/ 1024) as value FROM wp_options WHERE autoload='yes'
UNION
SELECT 'autoloaded data count', count(*) FROM wp_options WHERE autoload='yes'
UNION
(SELECT option_name, length(option_value) FROM wp_options WHERE autoload='yes' ORDER BY length(option_value) DESC LIMIT 10)
您也可以使用控制台执行任何其他需要的查询，例如对初始查询的结果进行排序。
您的计划应该是审查结果，找出哪些大型自动加载条目与什么相关，然后清理它们（即删除这些行）。
wp_postmeta：电商网站可能因元数据膨胀而崩溃
wp_postmeta 表 存储文章、页面和产品的自定义字段。每次保存内容时，都会添加新的元数据条目。插件尤其经常会将数十个字段附加到单个文章或产品上。
例如，WooCommerce 将产品数据 存储在 postmeta 中：变体、库存、运输详情和属性。一个带有变体的单一产品可以生成数十个元数据条目。大型产品目录可能产生数百万条 postmeta 行。
wp_postmeta 表膨胀的结果是编辑屏幕加载困难、产品过滤器速度变慢，以及搜索在尝试查询大型表时超时。一般来说，高流量期间的错误通常是由于 wp_postmeta 膨胀造成的。
您可以使用 SQL 控制台运行查询来选择和删除与 wp_options 类似的多余数据。您需要查找的是数 GB 大小的 postmeta 表、大量重复的 meta_keys，以及一般的孤立元数据。Database Studio 中的过滤选项对此也很有帮助：
例如，您可以通过单击列箭头按 meta_key 排序。这会将相同的键分组在一起，以便您发现模式，例如来自已删除插件或未使用的自定义字段的键。
wp_posts：无限修订导致编辑屏幕崩溃
wp_posts 表 存储内容和修订历史。默认情况下，WordPress 将每个更改保存为单独的数据库条目，因此常规内容编辑会产生大量额外数据。具有大量内容和编辑历史的站点可能会累积数千个修订条目。
最初，您的站点运行良好，但存储大量修订可能导致编辑文章时管理后台加载缓慢。WordPress 在编辑期间每 60 秒保存一次；自动保存也会产生负面影响，因为长编辑会话会创建数十个自动保存条目。
您可以快速清理 wp_posts 表中的修订（例如）：
然后您可以切换到 SQL 控制台运行查询并删除修订：
DELETE FROM wp_posts WHERE post_type="revision";
比较已发布文章的修订次数是一个不错的方法：个位数的比例是合理的。另外，还要查看修订版本是否超过总条目的一半，因为这表明可能存在膨胀。逐月增长的修订版本表明需要实施限制，您可以通过快速编辑 wp-config.php来实现。
插件表：表单和日志不断增长直至您的网站崩溃
几乎每个插件都会创建自定义数据库表，但表单、搜索和安全插件更为常见。这些表可能会持续增长，而不需要内置维护。
特别是，默认情况下表单插件通常会永久存储每次提交。因此，如果您的网站在多年内持续收到提交流量，您会积累数千条表单条目。更重要的是，与日志相关的表增长得更快。安全插件会记录访客操作，分析插件会跟踪页面浏览量，调试工具会记录错误。
与许多数据库表问题一样，页面会超时，但您也会看到数据库备份变慢以及与流量无关的性能下降。与数据库膨胀的连接并不总是显而易见的，因为症状出现在不相关的区域。
您需要查找与WordPress核心表大小相等或超过的插件表；它们越大，减少它们就越重要。SQL查询可以帮助您找出这些问题：
SELECT
TABLE_NAME AS `Table`,
ROUND((DATA_LENGTH + INDEX_LENGTH) / 1024 / 1024) AS `Size (MB)`
FROM
information_schema.TABLES
WHERE
TABLE_SCHEMA = "{database_name}"
ORDER BY
(DATA_LENGTH + INDEX_LENGTH)
DESC;
如果其中任何表是孤立的，您可以安全地删除它们。然而，虽然这超出了本文的范围，但如果任何表大到需要减少但它们仍然是您网站所需要的，您需要做一些研究——可能需要联系开发者寻求建议。
Action Scheduler：失败任务堆积导致结账崩溃
Action Scheduler本质上是为WordPress运行后台任务。它队列任务，异步处理，并默认永久存储完成记录。
使用WooCommerce是了解Action Scheduler如何导致问题的好方法。例如，支付网关超时会导致失败的操作，这些操作会永久保存在数据库中，并在每次页面加载时查询以检查待处理的工作。您可以从典型WooCommerce商店每月生成的数千个失败操作中推断出一个失败操作的情况。
Database Studio的Views可以帮助您删除这些失败的操作：
在这里，给视图一个标题，选择wp_actionscheduler_actions表，然后点击添加条件链接。这允许您只显示失败的操作，从而更简单地将它们从数据库中删除。
如何每月用10分钟管理您重要的WordPress数据库表
每月花几分钟的成本，您可以在一年中减少数据库管理工作。当然，您不必监控或管理数据库中的许多表：
wp_users表很少出现问题，除非您管理拥有数百万账户的会员网站。用户数据通常呈线性增长，不会积累任何膨胀。- 分类表（如
wp_terms、wp_term_taxonomy、wp_term_relationships）通常无论网站大小都保持稳定。
在五个问题表中，大型wp_posts表在内容网站上很常见，也是预期的。请记住：实际内容不是膨胀。
设置您的监控工作流程
导出数据库表让你可以在其他应用程序中使用数据。你可以通过任意表的更多项目省略号下拉菜单来完成此操作：
但是，在 MyKinsta 中无需导出也能完成很多工作。更好地利用时间的方式是自动化清理和手动检查数据库指标。Database Studio 的视图可以帮助你设置分析。
例如，你可以创建一个自定义视图来监控 wp_postmeta，并添加要跟踪的特定 meta_key 模式的过滤器：
Database Studio 允许你在 SQL 控制台中创建和保存代码片段，因此你可以设置一个 SQL 查询来按大小排序所有表，随时访问：
一些最大的表应该是 wp_posts、wp_postmeta 和 wp_options。你需要调查排名更高的任何表。
你设置的具体监控取决于你的站点和需求。以下是一些需要调查的方面：
- 过滤
wp_options中的活动自动加载，然后检查总大小（通过 SQL 查询或导出为 CSV）。任何超过 1MB 的都需要调查。 - 检查
wp_postmeta表大小与上月的对比，特别关注大幅增加。 - 你可以在
wp_posts中过滤 post_type 来比较修订版和文章。如果需要，在wp-config.php中设置限制。 - 对于 Action Scheduler，完成的操作数应超过待处理或失败的操作数。
总之，使用 Database Studio 创建你经常使用的视图、过滤器和查询代码片段。接下来，查找“危险”指标，然后使用其他工具自动化任何清理。例如，wp transient delete WP-CLI 命令 可以帮助你清除数据库中不需要的临时数据。
从被动修复到主动数据库维护
代理商最常处理的数据库问题并不罕见或不可预测。它们是熟悉模式的结果。应对这些问题和预防它们之间的区别在于专注。
你不需要检查每个表或审计每个查询。你需要知道数据库的哪些部分值得持续关注，以及如何在它们变成停机或紧急支持请求之前发现早期预警信号。
对于维护代理商来说，这改变了数据库工作如何融入你的工作流程。不要将数据库清理视为问题发生后的临时修复，而是将其变成一个轻量级、可重复的检查。
如果你确实遇到无法解决的数据库问题，特别是只在负载下出现的问题，拥有合适的支持很重要。对于托管在 Kinsta 上的站点，我们的支持团队全天候 24/7 为你提供帮助。
