WordPress每次渲染页面都会执行大量数据库查询，读取文章内容、配置选项、用户信息等都离不开MySQL。当访问量上来之后，数据库往往成为整个站点的瓶颈。对象缓存是WordPress内置的一套缓存抽象层，但它默认的实现只是把数据存放在PHP进程内存里，请求一结束就全部丢弃，等于没有跨请求缓存能力。把Redis接入WordPress之后，这些重复的查询结果可以在多个请求之间共享，数据库压力会显著下降。这篇文章就来完整讲清楚Redis与WordPress对象缓存的结合方式。
先弄懂WordPress对象缓存的工作机制
WordPress内部有一套缓存API，核心函数包括wp_cache_get、wp_cache_set、wp_cache_add和wp_cache_delete。当WordPress核心或插件需要频繁读取同一份数据时，比如options表中autoload的配置项，就会通过这些函数先查缓存，缓存未命中才回源到数据库。这套机制设计得很好，问题在于默认实现太弱。
WordPress默认的对象缓存驱动是放在wp-includes/cache.php中的内存版实现。它用一个PHP数组保存缓存对象，请求开始时数组为空，请求结束时数组销毁。也就是说，它只能减少单个请求内的重复查询，对跨请求的数据库压力几乎没有帮助。用户A访问过的文章，用户B访问时依然要重新查一遍数据库。
WordPress提供了drop-in机制来替换这套默认实现：只要在wp-content目录下放置一个object-cache.php文件，WordPress就会优先加载它而不是核心默认的缓存实现。Redis Object Cache等插件正是利用这个机制，把缓存后端从PHP数组切换为Redis服务器。理解了这一点，后面遇到缓存不生效的问题，第一件事就应该去检查wp-content/object-cache.php是否存在以及是否是有效版本。
Redis服务端与插件的安装配置
第一步是安装Redis服务端。以Ubuntu为例，执行下面的命令即可完成安装并启动：
sudo apt update sudo apt install redis-server -y sudo systemctl enable redis-server sudo systemctl status redis-server
安装完成后建议用redis-cli ping测试，返回PONG说明服务正常。生产环境强烈建议给Redis设置密码，编辑/etc/redis/redis.conf，找到requirepass一行，取消注释并填入强密码，然后重启服务。
第二步是PHP侧的Redis扩展。WordPress本身是PHP程序，它需要通过phpredis扩展与Redis通信。安装方法视PHP版本而定，以PHP 8.1为例：
sudo apt install php8.1-redis -y sudo systemctl reload php8.1-fpm php -m | grep redis
如果输出中能看到redis，说明扩展已就绪。也可以用php -i | grep redis查看更详细的配置信息。
第三步是在WordPress后台安装Redis Object Cache插件。安装启用后进入设置页，点击Enable按钮，插件会自动在wp-content下生成object-cache.php这个drop-in文件并连接Redis。更可控的做法是先在wp-config.php中手动写好连接参数：
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PASSWORD', '你的Redis密码');
// 多站点或同服务器多站点共存时务必设置前缀，避免key冲突
define('WP_REDIS_KEY_PREFIX', 'mysite:');
// 可选：设置最大内存策略相关，连接失败时让站点照常运行
define('WP_REDIS_MAXTTL', '86400');
define('WP_REDIS_DISABLE_BANNERS', true);
WP_REDIS_KEY_PREFIX这个参数很关键。如果一台Redis实例上跑了不止一个WordPress站点，不设置前缀会导致不同站点的缓存key互相覆盖，出现莫名其妙的内容串站问题。这是实战中最常见的坑之一。
验证效果、排查问题与性能优化建议
启用之后如何确认缓存真的生效了？最直接的办法是在前端页脚临时加一段调试代码，统计数据库查询次数：
add_action('wp_footer', function () {
if (current_user_can('manage_options')) {
echo '<p>数据库查询：' . get_num_queries() . ' 次，耗时 '
. timer_stop() . ' 秒</p>';
}
});
开启Redis前后各刷新几次页面对比数字。一般情况下，插件较多、内容较复杂的站点，查询次数能从一百多次降到几十次甚至更低。也可以在插件设置页查看缓存命中率和Redis内存占用，命中率长期保持在90%以上是比较健康的状态。如果命中率很低，要检查是否有插件频繁删除缓存，或者缓存TTL设置得过短。
常见问题方面，如果点击Enable后报连接失败，先按顺序检查三件事：phpredis扩展是否安装、Redis服务是否运行、密码或端口配置是否与redis.conf一致。远程连接Redis时还要确认bind配置和防火墙规则放行了WordPress服务器的IP，同时务必启用密码并关闭危险的FLUSHALL外部命令权限。另一个高频问题是启用缓存后页面出现过期数据，这通常是某个插件在数据更新时没有正确调用缓存清理函数，可以通过调整WP_REDIS_MAXTTL限制缓存最长生存时间来缓解。
性能层面还有几点建议。Redis的内存管理建议在redis.conf中设置maxmemory和maxmemory-policy allkeys-lru，让Redis在内存满时自动淘汰最久未使用的key，而不是因为写满而报错。如果服务器内存充裕，WordPress站点分配256MB到512MB通常已经绰绰有余。对于使用了页面缓存插件（比如Nginx层或WP Super Cache）的站点，对象缓存是很好的补充：页面缓存拦截匿名流量，对象缓存则覆盖登录用户和后台的动态请求，两者配合才能把数据库负载压到最低。
最后提醒一点，升级插件或WordPress版本后，object-cache.php可能需要同步更新，插件设置页会提示drop-in文件版本过旧，此时点击更新即可。养成在重大变更后检查缓存状态的习惯，可以让这套加速方案长期稳定地发挥作用。
RedisWordPress对象缓存Redis Object Cache插件修改时间：2026-09-05 10:26:31