WordPress Redis 对象缓存实战：把重复的 MySQL 查询砍掉

首页每次刷新都在跑同一批 SQL：查选项表、查分类、查最新文章。内容没变，数据库却一秒被问几百遍。对象缓存要解决的就是这件事——把查询结果放进内存，下一次直接读内存，不碰数据库。

WordPress 自带的对象缓存只在单次请求内有效，请求一结束就清空。Redis 把它变成跨请求持久的——这就是今天要装的。

请求链路长这样

浏览器 → Nginx → PHP-FPM；PHP 需要数据时，先问 Redis，命中就直接返回，没命中才去 MySQL，并把结果写回 Redis 供下次用。

一、装 Redis 和 PHP 扩展

以 Debian/Ubuntu 为例：

apt update
apt install -y redis-server php-redis
systemctl enable --now redis-server
# 确认扩展加载了
php -m | grep -i redis

如果是宝塔/aaPanel 面板，直接在「软件商店」装 Redis，再进 PHP 管理页的「安装扩展」装 redis 扩展即可。

Redis 默认只监听 127.0.0.1，本机用最安全：

# /etc/redis/redis.conf
bind 127.0.0.1
maxmemory 256mb
maxmemory-policy allkeys-lru

maxmemory-policy 设成 allkeys-lru —— 内存满了就淘汰最久没用的键，绝不因为缓存写满把服务拖垮。

二、告诉 WordPress 用 Redis 当对象缓存

在 wp-config.php（require_once ABSPATH . 'wp-settings.php'; 这一行之前）加入：

define( 'WP_REDIS_HOST', '127.0.0.1' );
define( 'WP_REDIS_PORT', 6379 );
define( 'WP_REDIS_TIMEOUT', 1 );
define( 'WP_REDIS_READ_TIMEOUT', 1 );
define( 'WP_REDIS_DATABASE', 0 );
// 多站点或同机多站时，用前缀隔离，避免互相覆盖
define( 'WP_CACHE_KEY_SALT', 'pddpdd.cn:' );

WP_CACHE_KEY_SALT 这一行别偷懒。同一台机器上跑多个 WordPress 时，没有前缀的几个站会共用同一批键，缓存互相污染，症状是"内容串站"——很难查。

三、装 drop-in 并开启

装插件 Redis Object Cache（后台搜 Redis Object Cache 即可），启用后进它的设置页点 Enable Object Cache。它会在 wp-content/ 下写一个 object-cache.php（叫 drop-in），WordPress 会自动加载它接管对象缓存。

点 Enable 之后，设置页会显示状态和 Hit rate（命中率）。

四、验证真的生效了

命令行直接看 Redis 里有没有 WordPress 的键：

redis-cli --scan --pattern '*wp*' | head
redis-cli info stats | grep keyspace

命中率目标：首次访问后，缓存命中率应稳定在 90% 以上。如果一直低于 70%，通常是这两个原因：

1. maxmemory 设太小，键被频繁淘汰；
2. 有插件每次都写唯一 key（比如带时间戳的统计），把缓存穿透了。

三个常见的坑

• 改完 wp-config 白屏：多半是 WP_CACHE_KEY_SALT 那行末尾漏了分号，或者插到 wp-settings.php 之后了。改前先备份 wp-config.php。
• 写文章后前台不更新：发布/更新文章时 WordPress 会自动 flush 相关缓存，正常；但如果装了页面缓存插件（如 WP Rocket），要额外清一次页面缓存。
• Redis 吃内存：maxmemory 建议给 128–256MB 起步，配合 allkeys-lru，一般够了。

值不值得装

如果你的站已经上了 Nginx + PHP-FPM，装 Redis 对象缓存基本是投入产出比最高的一步优化——不动主题、不改代码，十几分钟，数据库压力肉眼可见地降下来。先装，再看慢查询日志，顺序别反。