乐闻世界logo
5月31日 20:28

如何优化 WordPress 数据库才能真正提升性能？

WordPress 数据库优化不是把所有表都执行一遍 OPTIMIZE TABLE，而是减少无效数据、缩短慢查询、控制 postmeta 膨胀，并让缓存承担重复读取。很多网站首页慢，并不是 MySQL 不够强，而是修订版本、自动草稿、过期 transient 和插件日志表一起拖慢了查询。正确顺序是先备份，再定位慢点，最后才清理数据或改表结构。

追问

修订版本和自动草稿应该怎么处理？

修订版本有价值，但无限增长会让 wp_posts 和 wp_postmeta 变重。取舍上，多人协作站建议保留 3 到 10 个版本，小型展示站可以更少，但不建议完全关闭。清理前一定要备份，直接删 SQL 很快，删错状态也很难恢复。

php
define('WP_POST_REVISIONS', 5);
define('AUTOSAVE_INTERVAL', 120);
sql
DELETE FROM wp_posts WHERE post_type = 'revision';

OPTIMIZE TABLE 什么时候有用？

OPTIMIZE TABLE 对频繁删除、更新后产生碎片的表有帮助，但它不是万能性能按钮。InnoDB 表优化可能重建表，数据量大时会带来 IO 压力和锁等待。边界是小站可在低峰期执行，大站应先看表大小、碎片比例和业务窗口，别把它做成高频定时任务。

sql
SHOW TABLE STATUS LIKE 'wp_postmeta';
OPTIMIZE TABLE wp_posts, wp_postmeta, wp_options;

对象缓存和 transient API 怎么选？

对象缓存适合缓存 WordPress 内部对象和重复查询结果，配合 Redis 或 Memcached 后，多页面共享缓存更明显。Transient API 适合缓存首页热门文章、外部接口结果、复杂统计这类可过期数据。踩坑点是缓存键没有包含语言、用户角色或查询条件，最后不同用户看到同一份数据。

php
$key = 'home_hot_posts_v1';
$posts = get_transient($key);
if ($posts === false) {
  $posts = get_posts(['numberposts' => 10]);
  set_transient($key, $posts, 10 * MINUTE_IN_SECONDS);
}

慢查询应该怎么定位？

先用 slow query log 或 Query Monitor 找真实慢查询，再用 EXPLAIN 看扫描行数、索引和排序方式。WordPress 常见慢点是 meta_query、复杂 taxonomy 查询和无分页列表，尤其是把结构化数据大量塞进 postmeta 后。边界上，轻量字段可以继续用 postmeta，强筛选字段应考虑自定义表或专用索引。

sql
EXPLAIN SELECT post_id FROM wp_postmeta
WHERE meta_key = '_price' AND meta_value > 100;

高流量站是否一定要读写分离？

读写分离适合读多写少且单库读压力已经明显不足的站点。它会带来复制延迟，评论提交、订单支付、权限变化这类刚写完就要读的场景不能随便走只读副本。更稳的路线是先清理数据、治理慢查询、加缓存，最后才考虑副本或自定义表。

标签：WordPress