当客户报告后台管理界面运行缓慢、结账失败或随机超时时，代理机构没有时间去深入研究数十个数据库表或反向工程插件的行为。您需要快速识别可能的故障点，并将注意力集中在关键之处。
实际上，大多数严重的性能和稳定性问题都源于少数几个随着时间推移而不受控制地增长的数据库表。这些表在新网站或低流量网站上不会造成问题，但随着多年内容、插件和用户活动的积累，它们会导致不成比例的崩溃、查询缓慢和紧急支持工单。
本文重点介绍五个 WordPress 数据库表（以及表模式），维护机构应该积极监控这些表，因为它们最有可能随着网站的增长而导致实际的性能问题。
为什么机构只需监控数据库的20%？
帕累托法则有助于解释许多操作模式，它也适用于 WordPress 数据库维护。机构遇到的问题并非均匀分布在整个数据库中。相反，一小部分表导致了大部分与数据库相关的速度下降、崩溃和紧急支持工单。
标准的 WordPress 安装会创建 12 个默认表。其中一些表，例如 wp_users、wp_links 和 taxonomy 表，可以运行多年而不会出现问题。这些表通常不会触发在流量高峰期间导致网站崩溃的慢查询。
然而，这些高风险表有一个共同的特点：它们会导致大规模网站崩溃。一个拥有 100 篇文章的网站可能运行良好，并且拥有无限次的修订。但同一个网站，如果拥有 10,000 篇文章和 300,000 条修订记录，则很可能在每个编辑页面上都会超时。一个拥有 50 件商品的电商网站运行良好，但扩展到 5000 件商品时，页面加载速度可能会慢到几秒钟。
导致WordPress网站规模扩大后崩溃的五种数据库模式
让我们回顾一下代理维护工作中经常出现的五种模式。
它们在小型网站上不会立即造成危险，但随着内容、流量和插件活动的增加，它们会成为查询缓慢、超时和稳定性问题的最常见根源。
wp_options：自动加载膨胀可能导致高流量网站崩溃
wp_options 表存储网站设置和插件配置，并决定 WordPress 在每个页面请求（包括缓存页面）中加载哪些选项。在这些列中，autoload 是最重要的：
wp_options 表显示了若干列
WordPress 会在每次请求时首先将所有自动加载的选项加载到内存中。自动加载占用空间较小的网站可以正常处理流量，但随着自动加载量的增长，每个访问者消耗的内存将超过服务器为每个 PHP 进程分配的内存。
如果自动加载的大小过大（例如，超过 3MB 或更大），您会发现管理界面运行缓慢、销售期间结账失败以及出现 502 错误。
罪魁祸首几乎总是孤立的插件设置或称为“瞬态”的临时缓存条目。启用自动加载后，您删除的一些插件选项可能会保留在 wp_options 表中，这意味着它们会在每次请求时加载。几个月甚至几年下来，数十个插件积累的这些废弃数据会在每次页面浏览时加载。
数据库管理工具中的 SQL 控制台
如上图所示，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_options 表中的记录
您的计划应该是查看结果，确定哪些大型自动加载条目与之相关，然后清理它们（即删除这些行）。
wp_postmeta：电子商务网站可能因元数据膨胀而崩溃
wp_postmeta 表存储文章、页面和产品的自定义字段。每次保存内容时，都会添加新的元数据条目。特别是插件，通常会将数十个字段附加到单个文章或产品。
例如，WooCommerce 将产品数据存储在 postmeta 表中：变体、库存、运费详情和属性。一个包含变体的产品可能会生成数十个元数据条目。大型产品目录可能会创建数百万行 postmeta 数据。
wp_postmeta 表膨胀会导致编辑页面加载数据困难、产品筛选速度极慢，以及在尝试跨大型表进行查询时搜索超时。通常情况下，高流量期间的错误通常是由于 wp_postmeta 表数据过多造成的。
您可以使用 SQL 控制台运行查询来选择并删除冗余数据，类似于 wp_options 表。您需要查找诸如数 GB 的 postmeta 表、大量重复的 meta_key 以及其他孤立的元数据等问题。数据库管理工具中的筛选选项也很有用：
数据库管理工具界面显示了应用于数据库表的筛选器。
例如，您可以点击列箭头按 meta_key 排序。这会将相同的键分组在一起，以便您发现模式，例如来自已删除插件或未使用的自定义字段的键。
wp_posts：无限修订导致编辑屏幕崩溃
wp_posts 表存储内容和修订历史记录。默认情况下，WordPress 会将每次更改保存为单独的数据库条目，因此常规的内容编辑会生成大量额外数据。内容丰富且编辑历史记录较多的网站可能会累积数千个修订条目。
最初，您的网站运行良好，但存储的大量修订会导致您在编辑文章时管理屏幕加载缓慢。WordPress 在编辑期间每 60 秒保存一次；自动保存也会产生负面影响，因为长时间的编辑会话会创建数十个自动保存条目。
您可以快速清理 wp_posts 表中的修订（例如）：
数据库管理工具正在显示 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 商店每月生成的数千个失败操作中推断出一个失败操作的严重性。
数据库管理工具的“视图”功能可以帮助您删除这些失败的操作：
正在创建新视图的过程
在这里，为视图命名，选择 wp_actionscheduler_actions 表，然后点击“Add condition”链接。这样就可以只显示失败的操作，从而更轻松地将其从数据库中删除。
如何每月仅用10分钟管理重要的WordPress数据库表
每月只需花费几分钟，一年下来就能减少数据库管理工作。当然，您无需监控或管理数据库中的许多表：
- 除非您管理拥有数百万个帐户的会员网站，否则
wp_users表很少出现问题。用户数据通常呈线性增长，不会出现任何膨胀。 - 分类表（例如
wp_terms,wp_term_taxonomy,wp_term_relationships）通常保持稳定，不受网站规模的影响。
在五个问题表中，内容网站上的大型 wp_posts 表是常见且预期会出现的问题。记住：实际内容并非冗余信息。
设置监控工作流程
导出数据库表可以让您在其他应用程序中使用这些数据。您可以通过任何表的“更多项目”下拉菜单执行此操作：
大部分可视化数据库管理工具提供了导出表的选项。
不过，即使不导出数据，您也可以在一些数据库管理工具中完成很多工作。最有效的做法是自动化清理流程并手动查看数据库指标。数据库管理工具的视图功能可以帮助您设置分析。
例如，您可以创建一个自定义视图来监控 wp_postmeta 表，并添加过滤器来跟踪特定的 meta_key 模式：
为 wp_postmeta 表创建视图
数据库管理工具允许您在 SQL 控制台中创建和保存代码片段，因此您可以设置 SQL 查询，按大小对所有表进行排序，并在需要时随时访问：
创建 SQL 代码片段
一些最大的表应该是 wp_posts, wp_postmeta, 和 wp_options。您需要调查任何排名更高的表。
您设置的具体监控取决于您的网站和需求。但是，以下是一些需要关注的方面：
- 筛选
wp_options表中的活动自动加载项，然后检查总大小（通过 SQL 查询或导出为 CSV 文件）。任何大于 1MB 的表都应该进行调查。 - 将
wp_postmeta表的大小与上个月进行比较，特别是检查是否存在大幅增长。 - 您可以筛选
wp_posts表中的 post_type，以比较修订版本和文章。如有需要，请在wp-config.php文件中设置限制。 - 对于 Action Scheduler，已完成的操作数量应大于待处理或失败的操作数量。
总之，使用可视化数据库管理工具创建您常用的视图、过滤器和查询片段。接下来，查找“危险”指标，然后使用其他工具自动执行任何清理工作。例如，WP-CLI 命令 wp transient delete 可以帮助您清除数据库中不需要的瞬态数据。
从被动修复到主动数据库维护
机构最常遇到的数据库问题并非罕见或不可预测，而是源于一些常见的模式。应对这些问题和预防这些问题之间的区别在于关注点。
您无需检查每个表或审核每个查询。您需要了解数据库的哪些部分需要持续关注，以及如何在早期预警信号演变成服务中断或紧急支持请求之前发现它们。
对于维护机构而言，这将改变数据库工作在工作流程中的定位。数据库清理不再是故障发生后的一次性修复，而变成了一种轻量级、可重复的检查。
评论留言