evicted_keys计数是最直接的内存淘汰监控指标，表示Redis启动以来被强制删除的key总数，可通过INFO memory或redis-cli --stat实时观察其增量变化。
查 evicted_keys 计数是最直接的方式
Redis 会持续累计自启动以来被内存淘汰策略强制删除的 key 数量，这个值就存在 INFO memory 输出里，字段名是 evicted_keys。它不是“当前正在驱逐”，而是“到目前为止总共驱逐了多少次”——这是监控真实压力的核心指标。
- 运行
redis-cli INFO memory | grep evicted_keys，输出类似evicted_keys:12489 - 若用 Redis 6.2+，也可用
redis-cli --stat，最后一列就是每秒新增的驱逐数（注意它是差值，不是绝对值） - 云服务（如腾讯云、京东云）监控面板里的
redis_evicted_keys_per_sec指标，底层也是轮询这个值再做速率计算
CONFIG GET maxmemory-policy 决定驱逐是否真会发生
即使 evicted_keys 为 0，也不能说明没内存压力——如果策略是 noeviction（默认），Redis 遇到内存满时直接报错 (error) OOM command not allowed when used memory > 'maxmemory'.，根本不会触发驱逐。
- 先确认策略：
redis-cli CONFIG GET maxmemory-policy - 只有策略是
allkeys-lru、volatile-lfu等带 “evict” 行为的，evicted_keys才可能增长 - 误配成
noeviction却又没做好写失败兜底，业务会静默报错，比驱逐更难排查
用 redis-cli --stat 实时盯住驱逐速率
单次查 evicted_keys 只能看总量，要判断是不是突发尖峰，得看单位时间内的增量。这时候 redis-cli --stat 是最轻量、最贴近线上实况的方式。
- 执行
redis-cli --stat -i 2，每 2 秒刷新一行，其中倒数第二列（requests后面那个数）就是当前连接数；但关键在观察evicted_keys的变化趋势 - 示例输出中这一行：
8890 131.97M 47 0 1705992954 (+57) 2595，括号里的+57就是过去 2 秒新增的驱逐次数 - 如果连续几行都出现
+100、+200，说明内存已持续承压，不是偶发抖动
别只盯着 evicted_keys，顺手看看 expired_keys 和内存碎片
驱逐数飙升，有时并不是因为数据太多，而是过期 key 清理不及时，或内存碎片率（mem_fragmentation_ratio）过高导致可用内存虚低。
- 查过期键清理量：
redis-cli INFO stats | grep expired_keys，如果它远小于evicted_keys，说明淘汰主力不是 TTL 到期，而是策略主动干预 - 查碎片率：
redis-cli INFO memory | grep mem_fragmentation_ratio，> 1.5 就值得警惕，jemalloc 分配器在频繁删改后容易产生碎片，实际空闲内存够却报 OOM - 大 key 也会加剧驱逐：用
redis-cli --bigkeys扫描，一个 50MB 的 hash 被淘汰，等于干掉几百个小 key 的空间
