Redis缓存加速WordPress：安装Redis+配置WP Redis插件的完整操作
Redis 缓存加速 WordPress 的关键不在装什么软件，而在于让对象缓存真正落到内存里：装好 Redis 服务端、给 PHP 配上 redis 扩展、启用 WP Redis 插件生成 object-cache.php，最后用命中率验收。
场景一：日更资讯站，后台保存一次要等十几秒
有个日更约百篇的资讯站，跑在 2 核 4G 的云服务器上，环境是 MySQL 5.7 加 PHP 8.1。主编反馈两个现象：编辑点完"发布"要等十几秒才跳转，前台首页的 TTFB 忽高忽低；登上服务器用 top 一看，mysqld 长期吃掉一整个核。装上 Query Monitor 插件再看，单页执行了几百条 SQL，排名最靠前的几条反复是同一个形状——从 wp_options 表里按 option_name 取一条 option_value。
这不是主题写得差，而是 WordPress 的默认行为。它自带的所谓对象缓存只在单次请求的内存里活着，请求一结束就全部丢掉。下一次请求进来，autoload 为 yes 的全部 option、插件注册的 transient、菜单与设置项，又要重新去 MySQL 捞一遍。插件越多、主题越复杂，这份要捞的数据越大，开销越明显。
Redis 缓存加速 WordPress，本质就是把这一层"请求级内存"换成"跨请求的独立进程内存"：数据放在 Redis 里，PHP 通过扩展直接读，不再打数据库。这也是为什么收益最明显的地方往往是后台和登录态页面——这些页面本来就没法用页面缓存。
排查：先确认瓶颈真的是数据库
上 Redis 之前，先把"是不是数据库被重复查询压住"这件事确认掉，否则装了也白装。
- 装 Query Monitor（后台搜插件名即可），看每个页面的 SQL 条数、耗时排行、重复查询。如果耗时榜前几名反复是 wp_options 的读取，方向就对了。
- 查 autoload 体积：
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload='yes';。这个值到几 MB 就偏大，多半是卸载过的插件留下的垃圾 option，先清再缓存。 - 看云监控里 MySQL 的 CPU 与 QPS。访问量不大但数据库 CPU 常年偏高，是典型的重复读特征。
- 如果慢的是图片加载或第三方接口，Redis 帮不上忙，先修那一块。
结论很直白：对象缓存解决的是"同一份数据被反复查"的问题。前提不成立，它只会多出一个需要运维的进程。
动手环节：装服务、装扩展、启用插件
三条路径按环境选：面板党走宝塔，命令行党走 apt，容器里跑的自己把 Redis 做成 sidecar。
先装服务端。宝塔面板的路径是"软件商店 → 搜索 Redis → 安装"，装完记得在"软件 → Redis → 配置修改"里确认 bind 127.0.0.1、requirepass 视情况设置。命令行（Debian / Ubuntu）：
apt install redis-server -y
systemctl enable --now redis
redis-cli ping # 返回 PONG 就说明服务通了
如果是阿里云、腾讯云的 CentOS 系，把 apt 换成 yum install redis；用 Docker 的话 docker run -d --name redis -p 6379:6379 redis:7-alpine 也行，但要记得限内存、别把 6379 暴露到公网。
再装 PHP 扩展。宝塔走"软件商店 → PHP 8.1 → 设置 → 安装扩展 → 勾选 redis"，然后重启 PHP。命令行下 apt install php8.1-redis，如果你用的是自己编译的 PHP，就 pecl install redis，装完 systemctl reload php8.1-fpm，用 php -m | grep redis 确认扩展已加载。扩展版本必须和 PHP 大版本对齐，装错版本最典型的症状是后台一开插件就 500。
最后装插件。后台"插件 → 安装插件"搜 Redis Object Cache（作者 Till Krüss），启用后进"设置 → Redis"，点 Enable Object Cache。这一步会往 wp-content/ 写一个 object-cache.php 文件，它才是真正的开关：文件在，对象缓存就走 Redis；插件停用时这个文件会被移除，缓存自动退回数据库。
一机多站或者多站点网络，务必在 wp-config.php 里给每个站分配独立的键前缀或数据库：
define('WP_REDIS_HOST', '127.0.0.1');
define('WP_REDIS_PORT', 6379);
define('WP_REDIS_PREFIX', 'site_a:');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_TIMEOUT', 1);
define('WP_REDIS_READ_TIMEOUT', 1);
WP_REDIS_PREFIX 每站必须不同，否则缓存会互相串。
验证阶段：命中率、内存和失效策略
装完不等于生效，用几条命令把它按住。
redis-cli info stats 里看 keyspace_hits 与 keyspace_misses，隔一段时间取两次差值算命中率。内容站跑起来之后，命中率通常在八成以上；如果一直在低位，多半是 prefix 或 database 配错，缓存写完就没人读。
redis-cli info memory 看 used_memory_human，再用 redis-cli --bigkeys 找异常大的键。给 Redis 设个上限很必要，比如 maxmemory 256mb 配 maxmemory-policy allkeys-lru；如果设成 noeviction，内存写满后写入直接报错，前台表现是白屏、后台提示连接失败。
WordPress 侧用 WP-CLI 最快：wp redis status 会告诉你 drop-in 是否生效、用的是哪个库；wp cache flush 清一次。换主题、加插件、改设置之后清一次缓存，能避开大部分"改了没生效"的假故障。
场景二：一机两站串缓存，和 Redis 抢内存
坑一：同一台机器上放了两套 WordPress，都用了默认配置，也就是同一个 database 0。结果是 A 站的 option 被 B 站读到，编辑改完主题设置，前台显示的还是另一个站的样式，折腾半天找不到原因。解决办法就是前面写的那两行配置，让每个站有自己的前缀或独立的 database，改完 flush 一次即可。
坑二：Redis 与 MySQL 抢内存。4G 的机器上给 Redis 留几百 MB 就够，超了反而把 MySQL 挤到 swap 里，整体更慢。另外 WordPress 的 wp-cron 是访客访问时触发的，流量一上来定时任务频繁跑，缓存写入也跟着涨。可以把 DISABLE_WP_CRON 设为 true，改用系统 crontab 每五分钟调一次 wp cron event run --due-now，让定时任务可控。
结论：什么站点值得上，什么站点先别动
值得上的：日更内容站、装了 WooCommerce 或会员权限类插件、一台机器跑多个站、数据库 CPU 长期偏高的站点。这些站点的共同点是登录态请求多、option 与 transient 反复读，Redis 的收益能直接体现在后台操作速度和数据库负载上。
可以先不动的：日均访问量很小的纯展示站、已经上了全页缓存而且插件很少的站。这类站点的瓶颈通常不在数据库，多个 Redis 反而多了一个要监控、要限制内存的组件；访问量小的时候，PHP 自带的请求级缓存已经够用。
判断方法也简单：上之前先备份数据库，装上之后盯一天的命中率、内存曲线和 MySQL 的 CPU，如果命中率上不去、CPU 没降，就把它关掉，成本不过是半小时。