命中率= get_hits / (get_hits + get_misses) × 100%，需用 telnet 或 nc 获取 stats；连接数看 curr_connections 而非 total_connections；stats sizes 会阻塞服务，禁用。
直接看 stats 输出里的 get_hits、get_misses 和 curr_connections，就能算出命中率、确认当前连接数——不需要额外工具，也不依赖客户端库。
用 telnet 或 nc 获取原始 stats 数据
Memcached 本身不提供“一键命中率”命令，所有指标都藏在 stats 响应里。最轻量、最通用的方式就是发原始协议命令：
- 运行
echo "stats" | nc 127.0.0.1 11211（替换 IP 和端口） - 或用
telnet 127.0.0.1 11211连上后手动输入stats，再按Ctrl + ]退出 - 关键字段必须关注：
get_hits、get_misses、curr_connections、total_connections - 注意：响应末尾一定有
END行，别把它误当成统计值
命中率怎么算？别信 cmd_get
很多教程教用 get_hits / cmd_get * 100%，这会高估真实命中率——因为 cmd_get 包含了所有 get 请求，但有些请求根本没进缓存逻辑（比如 key 格式错误、协议解析失败），它们不会计入 get_hits 或 get_misses，却会计入 cmd_get。
- 正确公式是：
get_hits / (get_hits + get_misses) * 100% - 验证方式：检查
get_hits + get_misses是否 ≈cmd_get；如果差值 > 5%，说明存在协议层异常或客户端误用 - 低于 80% 要警惕；持续低于 60% 通常意味着缓存设计不合理或热点数据未预热
连接数要看 curr_connections，不是 total_connections
total_connections 是自启动以来累计建立的连接总数，对实时运维毫无意义；真正关键的是 curr_connections——它代表当前活跃 TCP 连接数。
- 如果
curr_connections长期接近或超过maxconns（默认 1024），会出现连接拒绝，客户端报Connection refused或超时 - 查当前配置的连接上限：启动时用了
-c参数（如memcached -c 2048），或看stats settings中的maxconns字段 -
connection_structures是已分配的连接结构体数量，应略大于curr_connections；若远大于，说明连接泄漏（比如客户端没 close）
别碰 stats sizes，它会锁服务
stats sizes 看起来能帮你了解 key 分布，但它会阻塞所有请求，直到遍历完全部 item——在生产环境执行等于主动制造雪崩。
- 它不是只读快照，而是全表扫描+加锁，实测在 100 万 item 的实例上可能卡住 2–5 秒
- 替代方案：用
stats items查各 slab class 的 item 数量，或用memcache-top这类带缓存聚合的工具 - 如果真需要 size 分布，应在低峰期用
stats cachedump <slab_id> 0</slab_id>分批导出，且每次只 dump 一个 slab
真正难的不是拿到数字，而是理解这些数字背后的服务状态：比如 evictions 在涨但 curr_connections 很低，说明是内存不足而非并发高；get_misses 突增但 cmd_set 几乎为 0，大概率是缓存穿透。盯住这三个字段组合，比单看命中率有用得多。
