WordPress 接上 Redis 对象缓存（2026 实操）：命中率 92%，数据库少接五千八百万次查询

翻 Redis 的运行统计，keyspace_hits 是 58215653，keyspace_misses 是 4444078，算下来命中率 92.9%。意思是过去 53 天里，五千八百万次数据请求在内存里就解决了，只有四百多万次落到 MySQL 头上。

加对象缓存这事我拖了很久，理由是站里已经有 Cache Enabler 和 ESA 边缘缓存，感觉不缺缓存。真正让我动手的是登录状态下的后台，页面缓存对登录用户不生效，wp_options 和 post meta 每次刷新都要重新查一遍，php-fpm 子进程就一直占着，跟我上次查 502 时算的那笔内存账其实是同一件事。

一、它管的是哪一层

页面缓存把整页 HTML 存成文件或者推到边缘节点，只对未登录访客有效，命中之后 PHP 根本不跑。对象缓存管的是 WordPress 内部的 wp_cache 调用，也就是 options、post meta、用户、查询结果这些东西，它替换掉的是默认那个「只活在单次请求里」的内存缓存。页面缓存省的是整趟 PHP，对象缓存省的是数据库往返，登录用户、后台、REST 请求都能吃到。

两层不冲突，也不互相替代。你的站要是页面缓存都还没配，先去做那一层，收益更直接。

二、前置条件

1. Redis 服务在跑。redis-cli ping 应该回 PONG，redis-cli info server | grep redis_version 我这边是 7.2.11，以你的环境为准。
2. PHP 的 redis 扩展装好。php -m | grep -i redis 有输出才算。宝塔在软件商店里点 PHP 8.1 的「安装扩展」，找到 redis 装上，装完 /etc/init.d/php-fpm-81 reload。
3. 确认 Redis 只监听本机。我的 redis.conf 第 69 行是 bind 127.0.0.1，6379 别往公网开，对象缓存里会有登录态的碎片。

三、接上它

1. 装插件。最省事的是官方那个 redis-cache：wp plugin install redis-cache --activate。想用 prefetch 和更细的诊断，就上 Object Cache Pro，我这边装的是它，版本 1.20.2。

1. 把连接参数写进 wp-config.php：

define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'littlesheep');
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);

用 WP-CLI 写也行，数字记得加 --raw，不然会被引号包成字符串：

wp config set WP_REDIS_PREFIX littlesheep
wp config set WP_REDIS_DATABASE 0 --raw

一台 Redis 上跑多个站，DATABASE 和 PREFIX 至少有一个要区分开，不然键会串。

1. 启用 drop-in：wp redis enable。如果 wp-content 下已经有 object-cache.php，它不肯覆盖，加 --force。

1. 看状态：wp redis status，出现 Status: Connected 就算接上了。

四、怎么确认它真在干活

插件页面写 Connected，不代表有数据在流转，往 Redis 那边看一眼更实在：

redis-cli info stats | grep -E "keyspace_hits|keyspace_misses"
redis-cli dbsize
redis-cli --scan --pattern "littlesheep*" | head

我这边 dbsize 是 19431 个键，用前缀扫出来一堆 littlesheep:options、littlesheep:post_meta 开头的条目，这才说明缓存真的在写。刚接上的一两个小时命中率会很难看，让它跑一天再看数字。

还有个命令是 wp cache type，输出 Redis 就说明对象缓存已经换掉了默认实现。

五、我踩过的两个坑

第一个是 WP-CLI 报扩展不存在。站点前台一切正常，wp redis status 却直接甩一句 requires the redis PHP extension。原因是 wp 跑的 PHP 跟网站不是同一个，wp --info 显示 PHP binary 是 /www/server/php/82/bin/php，而我的 redis 扩展装在 8.1 上。想看站点的真实状态，就用站点那个 PHP 去跑：

/www/server/php/81/bin/php /usr/local/bin/wp redis status

顺带一句，宝塔的 php.ini 和 php-cli.ini 是两个文件，扩展只在其中一个里加载就会出现「网页好用、命令行报错」这种分裂现象，我这边 8.1 两份都写了，只加一份够你查半小时。

第二个是 maxmemory 没设。今天翻配置才发现，redis-cli config get maxmemory 返回 0，等于不设上限，策略是 noeviction，意思是真到了上限，写操作直接报错而不是淘汰旧键。机器总共 1.9G 内存，Redis 现在只用 14MB 看着很乖，但基线一直涨的话它迟早跟 mysqld 抢，而上次被内核 OOM 杀掉的就是 mysqld。给个上限更稳：

redis-cli config set maxmemory 256mb
redis-cli config set maxmemory-policy allkeys-lru
redis-cli config get maxmemory

这两条只在当前进程里生效，重启就没，要永久得写进 /www/server/redis/redis.conf。对象缓存的数据丢了一点不心疼，allkeys-lru 让它自己淘汰就行。

六、出问题怎么退回去

最轻的开关是这一行，加到 wp-config.php 里，drop-in 立刻失效但文件还在，删掉这行就恢复：

define('WP_REDIS_DISABLED', true);

彻底一点用 wp redis disable 摘掉 drop-in，或者直接把 wp-content/object-cache.php 删了，停插件是 wp plugin deactivate redis-cache。

WP_REDIS_TIMEOUT 设成 1 秒是有意的，Redis 卡住的时候请求一秒就放弃，不会拖着一堆 php-fpm 子进程干等到 502。另外 wp redis flush 清的是整个库不是单个站，共用 DB 的场合慎用。

缓存的价值在于它不出声，服务器内存账、备份、图片体积这几件事也一样，平时看着都没事。相关的几篇在这里：全站自动备份与恢复、502 和白屏排障、图片瘦身实操，想用 Object Cache Pro 的话站里也放过资源帖。