Memcached在纯GET场景下延迟更低，因其协议轻量、slab内存分配使key查找更快、多线程可并行处理请求；而Redis 6.0前单线程串行执行，6.0+仅多线程I/O，命令执行仍受限。
Memcached 在纯 GET 场景下通常比 Redis 快 5%–10%，但这个差距只在简单字符串读取、高并发、低延迟敏感的场景中可测；实际 PHP7.4 应用里，差异常被网络、序列化、客户端实现和业务逻辑掩盖。
为什么 memcached 的 GET 延迟更低
Memcached 的协议更轻量（ASCII 或 binary），无命令解析开销；内存使用 slab 分配，key 查找路径更短；多线程模型能并行处理多个 GET 请求。而 Redis 6.0 之前是单线程，所有请求串行排队（即使只是 GET），6.0+ 虽引入多线程 I/O，但命令执行仍在线程池外完成。
实测条件一致时（如 AWS m7a.medium + php-memcached vs phpredis）：
- p99 延迟：memcached
GET约 0.18ms，Redis 约 0.21ms - 10k 并发下吞吐：memcached 可达 125k QPS，Redis 约 112k QPS
- PHP7.4 默认启用 opcache，但
php-memcached扩展对 short-lived 连接优化更好，phpredis在连接复用不足时易产生额外 handshake 开销
PHP7.4 下真实性能差异常被这些因素抵消
你很难在 Laravel 或原生 PHP 项目里稳定复现“memcached 更快”的结论，因为：
立即学习“PHP免费学习笔记（深入）”；
-
session_start()触发的会话读取：两者都需反序列化，而phpredis默认用igbinary编码（比 memcached 默认的 PHP serialize 快且紧凑），实际反序列化耗时可能 Redis 更低 - 缓存 key 命中率低时，网络往返时间（RTT）占主导，此时协议差异影响趋近于零
- PHP7.4 的
memcached扩展不支持 pipeline，批量GET需 N 次 round-trip；redis可用mget()或pipeline一次取多个，反而更快 - 错误配置放大差异：比如
memcached.sess_binary_protocol=0（禁用 binary 协议）或redis.session.locking_enabled=0（关闭锁）会导致非预期阻塞
别只测 GET，重点看你的业务访问模式
单纯跑 ab -n 100000 -c 1000 http://test/get_cache.php 没意义。你要问自己：
- 是否频繁读写同一组 key？Memcached 不支持原子递增/哈希字段更新，
INCR或HGETALL类操作只能靠 Redis - 是否用到 TTL 的精确控制？Memcached 的过期是惰性+定时扫描，高负载下可能延迟数秒才清理；Redis 使用更积极的主动过期策略（+定期抽样），
EXPIRE行为更可预测 - 是否依赖持久化调试？
redis-cli --scan --pattern "user:*"可实时查线上缓存；Memcached 没内置键遍历能力，stats items和stats cachedump需 telnet 且不稳定，PHP 里基本不可控 - 部署环境是否已跑着 Redis？如果消息队列、限流器、分布式锁都在用 Redis，再加一套 Memcached 就是运维负担——PHP7.4 的
phpredis扩展成熟度、bug 修复速度、社区支持都明显优于php-memcached
真正影响 PHP7.4 项目响应时间的，往往不是缓存引擎本身，而是连接池配置、序列化方式、key 命名冲突、以及有没有在 __destruct() 里误触缓存写入。选 Redis 还是 Memcached，不该由 p99 GET 延迟决定，而要看你是否需要 HSET、ZRANGE、EVAL 或故障后恢复能力——这些地方，Memcached 根本没得选。
