本文约 3,475 字，预计阅读 9 分钟。文中命令与配置均经过实测，可直接参考执行。
引言：两个都能用，到底装哪个
要给 WordPress 装对象缓存时，很多教程一会儿说 Redis，一会儿说 Memcached，看得人犯迷糊。尤其宝塔面板里两个扩展都有，随便装一个可能踩坑：
- 装了 Memcached，发现某些插件的高级功能（如分组清除）不可用；
- 装了 Redis，发现内存占用偏高；
- 有的插件只支持其中一种，装错了插件直接报 “Backend not available”。
其实两者在 WordPress 场景下都能正常工作，差异体现在细节和生态上。
原理分析：核心差异
| 维度 | Memcached | Redis |
|---|---|---|
| 数据结构 | 只有 key-value 字符串 | 字符串、Hash、List、Set、ZSet、Stream |
| 持久化 | 无（纯内存，重启全丢） | 支持 RDB / AOF |
| 内存模型 | Slab Allocation，预分配固定大小 chunk | 直接分配 + jemalloc |
| 多线程 | 多线程（1.5+ 支持） | 单线程（6.0+ 有多线程 IO） |
| 单 key 大小 | 默认上限 1MB | 上限 512MB |
| Key 长度 | 250 字节 | 无实际限制 |
| 集群 | 客户端一致性哈希 | 原生 Cluster |
| 过期策略 | LRU（惰性） | LRU / LFU，可配置 |
| WordPress 生态 | 老牌支持（W3TC、Batcache） | 现代主流（Redis Object Cache、LiteSpeed、W3TC） |
对 WordPress 最实际的三点差异：
- 1MB key 限制：Memcached 单个 value 不能超过 1MB。WordPress 里如果有插件缓存了很大的数据（比如整页 HTML、超大
alloptions），会静默失败——写入不报错，但读不到。Redis 没有这个问题。 - WordPress 的 key 长度：WordPress 生成的缓存 key 形如
mimangfei_default:post_meta:12345，Memcached 250 字节限制一般是够的，但多站共享时前缀一叠就容易超。 - 分组清除（Group Flush）：Redis 的 Hash 结构可以按 group 整体删除（比如”清空所有 post 缓存”），Memcached 做不到，只能全清或按 key 逐个删。现代插件（Redis Object Cache）依赖这个特性。
结论导向：新站点优先 Redis；老站点已在用 Memcached 且稳定，不必强迁。
保姆级实操
方案 A：安装 Memcached
sudo apt install memcached libmemcached-tools php8.2-memcached -y
sudo systemctl enable --now memcached
配置 /etc/memcached.conf：
-m 256 # 内存 256MB
-p 11211
-l 127.0.0.1 # 只监听本机
-c 1024 # 最大连接数
-U 0 # 关闭 UDP（防放大攻击）
重启并测试：
sudo systemctl restart memcached
echo -e "set test 0 60 5\r\nhello\r" | nc 127.0.0.1 11211
# 返回 STORED
装插件：Memcached Redux（Drop-in 版）或 W3 Total Cache（在 Database Cache / Object Cache 里选 Memcached）。
手动部署 drop-in：
cp wp-content/plugins/memcached-redux/object-cache.php wp-content/
wp-config.php：
global $memcached_servers;
$memcached_servers = array( '127.0.0.1:11211' );
define( 'WP_CACHE_KEY_SALT', 'mimangfei_' );
方案 B：安装 Redis
详见 WordPress 配置 Redis 对象缓存，这里给最简版：
sudo apt install redis-server php8.2-redis -y
# 装 Redis Object Cache 插件，启用即可
方案 C：两者共存
可以，但不要同时启用两个 object-cache drop-in（wp-content/object-cache.php 只有一个）。想让不同用途用不同后端，只能通过插件自己的配置接口指定，比如 W3 Total Cache 允许「数据库缓存用 Memcached，对象缓存用 Redis」。
验证是否生效
Memcached：
echo "stats" | nc 127.0.0.1 11211 | grep -E "get_hits|get_misses|bytes"
计算命中率：get_hits / (get_hits + get_misses)。
Redis：
redis-cli -a 密码 info stats | grep -E "keyspace_hits|keyspace_misses"
用 Query Monitor 验证效果
装 Query Monitor 插件，对比开启前后：
- SQL 查询次数：
alloptions类的重复查询应大幅减少； - 页面生成时间：数据库时间（DB Queries Time）应显著下降。
典型的开启前/后对比（2 核 4G、中等规模站）：
| 指标 | 开启前 | 开启 Redis 后 |
|---|---|---|
| 数据库查询数 | 68 次 | 15 次 |
| 数据库耗时 | 45ms | 8ms |
| 页面生成时间 | 320ms | 190ms |
| TTFB（登录态） | 900ms | 480ms |
常见踩坑
- 装了 PHP 扩展名字没分清：
php-memcache（老扩展，无 ‘d’）和php-memcached（新扩展）是两个东西，功能和 API 都不同。装新的那个带 d 的。 - Memcached 静默失败：超过 1MB 的值写不进去，且不报错。如果开了缓存但某些页面毫无改善，检查一下
alloptions大小：
sql
SELECT SUM(LENGTH(option_value))/1024 AS kb FROM wp_options WHERE autoload='yes';
超过 800KB 就危险了，Memcached 可能装不下。清理方法见WordPress 数据库优化与索引清理。
STATS显示连接数打满：-c 1024不够，调大到 4096，或查是不是有慢连接。- 重启服务器后缓存全丢：Memcached 是纯内存，重启必丢。这是设计如此，不是故障。Redis 可选持久化，但对象缓存场景建议关掉持久化，丢了重建即可。
- 案例：某站从 Memcached 换到 Redis，配置完发现后台”设置 – Redis”一直显示
Status: Not Connected，但前台明显变快了。原因是该站装了 W3 Total Cache，它的 drop-in 覆盖了 Redis Object Cache 的。卸载其中一个即恢复正常。 - 多站点（Multisite）：WordPress 多站点模式下，缓存 key 会自动加
blog_id前缀，一般不用额外处理，但WP_CACHE_KEY_SALT仍建议设。
总结
选型建议一句话：新站直接上 Redis，生态好、无 1MB 限制、支持分组清除、可视化插件成熟；已经在跑 Memcached 且稳定的站不必折腾；只用 W3 Total Cache / Batcache 的老站继续用 Memcached 即可。无论选哪个，三件事必做：只监听 127.0.0.1、设好 WP_CACHE_KEY_SALT 防串站、上线后验证命中率。缓存只是性能优化的一环，配合Nginx FastCGI 缓存配置和OPcache 参数调优效果才完整。
