做运维和开发这些年，Redis 基本是绕不开的一个组件。缓存、session、分布式锁、排行榜、消息队列，样样都有它的影子。而要在 Linux 服务器上把它用得顺手，核心靠的就是那一批常用命令。这些命令看着简单，但真正到了生产环境，怎么用、用哪个、哪些命令有坑，其实有不少门道。今天就把我日常在 Linux 下操作 Redis 的高频命令整理一遍，把命令背后的原理和适用场景也一并说清楚，希望能帮你省点试错的时间。
1. 先把 Redis 命令体系在脑子里搭个框架
1.1 为什么记命令之前要先理解数据结构
很多人学 Redis 命令喜欢上来就背 SET、GET、HSET、LPUSH，背得挺熟，但一遇到实际业务就不知道怎么选型。根本原因是没有把命令跟底层数据结构对应起来。
Redis 的核心模型是 key-value，但 value 的类型并不单一。它包含 String、Hash、List、Set、ZSet 五大基础类型，以及 Bitmap、HyperLogLog、Geo、Stream 等扩展类型。每种类型的命令集都是独立的一套 API，用途完全不同。所以建议你把命令的学习思路从“记命令”切换成“按类型记方法”，就像 Java 里每个类有自己的一组方法一样，String 类型有 String 的方法，Hash 类型有 Hash 的方法，别混着用。
选错数据类型是生产事故的高发原因。比如想存用户信息，有人直接用 String 拼接 JSON，存取都要做序列化和反序列化；如果改用 Hash，每个字段可以独立读写，性能和灵活性完全不是一个量级。
1.2 命令分类：全局、数据类型、运维各管一摊
Redis 命令总数超过 200 个，但日常高频用到的其实只有几十个。按用途我把它们分为三类：
- 全局命令：针对 key 本身的通用操作，如 DEL、EXISTS、EXPIRE、TTL、TYPE、KEYS、SCAN，不关心 value 是什么类型。
- 数据类型命令：针对特定数据结构的增删改查，如 String 的 SET/GET，Hash 的 HSET/HGET，List 的 LPUSH/RPOP 等。
- 运维管理命令：用于查看 Redis 运行状态、持久化、复制、客户端连接管理等，如 INFO、CONFIG、CLIENT、DBSIZE、MONITOR。
理解了这三类的分工，你拿到一个需求时就能很快定位该去哪一组命令里找方案。下面我按顺序把这些命令串一遍，每一类都挑重点讲，实战中容易踩坑的地方会单独标注。
2. 全局命令与 Key 操作：日常用得最多的一批
2.1 Key 的增删查改与过期管理
先看最基础的一组命令。SET 和 GET 是 String 类型的核心，但很多人忽略了它们其实是“key 维度”的入口。先有 key，才有 value 的类型之分，而全局命令不关心 value 是什么，只对 key 本身操作。
常用的 key 管理命令：
EXISTS key：判断 key 是否存在，存在返回 1，不存在返回 0。这个命令在业务代码里经常用于缓存判空。DEL key [key ...]：删除 key，可以一次删多个，返回删除成功的数量。注意 DEL 是同步阻塞命令，如果一个 key 里的 value 很大（比如几百 MB 的 List），删除时会阻塞 Redis 主线程，生产环境要格外小心。TYPE key：查看 key 对应的 value 类型，返回 string、list、hash、set、zset 等。EXPIRE key seconds：给 key 设置过期时间，单位是秒。这是 Redis 缓存淘汰的重要机制，所有缓存 key 都应该设置合理的过期时间，避免冷数据长期驻留内存。TTL key：查看 key 剩余存活时间。返回 -1 表示永不过期，返回 -2 表示 key 不存在。PERSIST key：移除过期时间，让 key 永久有效。
这里有个常见的误区需要提醒。很多新手认为设置了 EXPIRE 就万事大吉，其实 Redis 对过期 key 的清理有两种方式：惰性删除和定期删除。惰性删除是当 key 被访问时才检查是否过期，如果一直不被访问就一直在内存里占着；定期删除是后台周期性抽查一部分 key 来清理。所以如果你的业务里大量设置了过期时间相近的 key，同时这一刻又恰好是访问低谷，Redis 可能来不及清理全部过期 key，内存占用会短暂偏高，这是正常现象，不用太惊慌。
实际动手操作一下。在 Linux 终端里执行redis-cli进入命令行交互模式，然后依次执行：
127.0.0.1:6379> SET user:10086 "zhangsan" OK 127.0.0.1:6379> EXPIRE user:10086 60 (integer) 1 127.0.0.1:6379> TTL user:10086 (integer) 57 127.0.0.1:6379> TYPE user:10086 string 127.0.0.1:6379> DEL user:10086 (integer) 12.2 SCAN 命令替代 KEYS 的实战理由
KEYS 命令恐怕是 Redis 命令里“名气最大”的坑。KEYS pattern能按模式匹配返回所有 key，比如KEYS user:*。在只有几十个 key 的开发环境没问题，但在生产环境，如果 key 数量达到百万级别，KEYS 会直接阻塞 Redis 主线程，导致所有读写请求排队，严重时就是一场事故。
替代方案是 SCAN 命令。SCAN 采用游标迭代的方式，每次返回一部分 key，不会阻塞主线程，适合在生产环境安全地遍历 key。
redis-cli --scan --pattern 'user:*' --count 1000在命令行交互模式下，SCAN 的用法是：
127.0.0.1:6379> SCAN 0 MATCH user:* COUNT 100 1) "23" 2) 1) "user:10086" 2) "user:10087"返回结果的第一个元素是下一次迭代的游标，当游标回到 0 时表示遍历完成。COUNT 不是精确返回条数，而是影响每次迭代的耗时上限，实际返回的 key 数量可能比 COUNT 稍多，这是正常行为。
这里要强调一下 SCAN 和 KEYS 的本质区别。SCAN 可以理解为“分批拉取”，KEYS 则是“一次性全量扫描”。对于需要全量遍历 key 做统计或清理的场景，一定用 SCAN 而不是 KEYS，这是生产环境最基本的红线之一。
2.3 几个容易被忽略的全局命令
还有几个命令，使用频率没有 SET/GET 高，但特定场景下特别好用：
RENAME key newkey：重命名 key。注意如果 newkey 已经存在，RENAME 会直接覆盖它，不会报错。如果不想覆盖，可以用RENAMENX key newkey，当 newkey 存在时返回 0。RANDOMKEY：随机返回一个 key，适合做抽样分析。UNLINK key：异步删除 key。与 DEL 不同，UNLINK 在后台释放内存，不会阻塞主线程。删除大 key 时优先用 UNLINK，这几乎是现在大厂运维的标配操作。
以删除一个包含百万元素的 List 为例，DEL 可能阻塞主线程几百毫秒，甚至更久，而 UNLINK 几乎瞬间返回。这个差异在业务高峰期可能就是事故与平稳的区别。
3. 五大数据类型命令详解：从 API 到业务场景
3.1 String：不只是缓存值
String 是最基础的类型，Redis 的 key 本身也是 String。它可以存字符串、整数、浮点数、二进制数据，最大 512 MB。除了 SET/GET 之外，还有一组命令在生产环境用得非常多。
SETNX key value：当 key 不存在时才设置成功，返回 1，否则返回 0。这是实现分布式锁的基石命令。SETEX key seconds value：设置值并同时指定过期时间，相当于 SET + EXPIRE，原子操作。MSET / MGET：批量设置、批量获取多个 key，减少网络往返。INCR / DECR / INCRBY / DECRBY：对整数值做自增、自减操作。这是计数器场景（如访问统计、库存扣减）的核心命令。SETRANGE / GETRANGE：对字符串的偏移量做操作，一般用于位图、特定格式数据的局部更新。
一个典型的计数器场景：文章阅读数，每次有人访问就对article:readcount:10001执行 INCR。这个操作是原子的，不像先 GET 再 SET 那样存在并发覆盖问题。
还要提一下 SET 命令的扩展参数，在 Redis 2.6.12 之后，SET 本身就可以支持 NX 和 EX 参数：
SET key value NX EX 10意思是“只有当 key 不存在时设置，并且 10 秒后过期”。这比分开执行 SETNX 和 EXPIRE 更安全，因为两个命令分开执行时中间可能出现进程崩溃，导致 key 永不过期的脏数据。
3.2 Hash：对象结构化存储的首选
Hash 可以理解成 key 下面挂了一个 field-value 的映射表。对于用户信息、商品信息这种有多个属性的对象，用 Hash 存储比用 String 存 JSON 方便得多。
常用命令：
HSET key field value：设置单个字段，如果 field 已存在则覆盖，返回 0；新增则返回 1。HMSET key field1 value1 field2 value2：批量设置多个字段。HGET key field：获取单个字段值。HMGET key field1 field2：批量获取多个字段值。HGETALL key：获取所有字段和值，注意生产环境如果字段非常多会占用较大网络带宽，建议用 HSCAN 分批获取。HDEL key field [field ...]：删除字段。HEXISTS key field：判断字段是否存在。HINCRBY key field increment：对 Hash 中某个字段做自增操作。
举个例子，存一个用户信息：
HSET user:10001 name "zhangsan" age 25 city "hangzhou" HGET user:10001 name HGETALL user:10001Hash 的底层实现有两种：ziplist 和 hashtable。当字段数量少、值较小时用 ziplist 节省内存；字段多或值大时自动转为 hashtable。这个转换由 Redis 自动完成，一般不需要我们干预，但了解这一点有助于理解为什么小 Hash 那么省内存。
3.3 List：消息队列的原始形态
List 是一个双向链表，头尾操作复杂度都是 O(1)。常用命令：
LPUSH key value：从左边推入一个值。RPUSH key value：从右边推入一个值。LPOP key：从左边弹出一个值。RPOP key：从右边弹出一个值。LRANGE key start stop：获取指定范围内的元素，LRANGE list 0 -1获取全部。LLEN key：获取列表长度。LTRIM key start stop：只保留指定范围内的元素，其余删除。
List 最常见的应用是消息队列。生产者 RPUSH，消费者 LPOP，就实现了一个最简单的 FIFO 队列。但这里有个问题：LPOP 是阻塞的还是没有阻塞？如果消费者执行 LPOP 时队列是空的，它会立刻返回 nil，而不是等待。这种轮询方式会有性能浪费。
Redis 提供了阻塞版本的命令：BLPOP和BRPOP。消费者可以指定超时时间：
BLPOP queue 30这行命令表示从 queue 列表左边弹出元素，如果队列为空，最多阻塞 30 秒。这种方式比轮询省资源，也能保证消息的实时性。
用 List 做消息队列有一个明显问题：不支持消息确认和重复消费，消费者一旦 POP 出来，消息就没了。如果消费端处理崩溃，消息就会丢失。所以 List 队列适合对消息可靠性要求不高的场景，比如日志收集、异步通知。需要可靠投递的场景，建议用 Redis Stream 或者专业消息队列组件。
3.4 Set：去重与集合运算
Set 是一组无序、唯一、无序的字符串集合。它的核心特性就是成员唯一性和集合运算能力。
常用命令：
SADD key member：增加成员，如果成员已存在返回 0。SREM key member：删除成员。SMEMBERS key：获取全部成员。SISMEMBER key member：判断成员是否存在，时间复杂度 O(1)。SCARD key：获取集合元素数量。SINTER key1 key2：取交集。SUNION key1 key2：取并集。SDIFF key1 key2：取差集。SPOP key：随机弹出一个元素，可用于抽奖去重。
一个非常经典的场景是抽奖活动。用户参与抽奖时执行SADD lucky:20250101 user:10001，因为 Set 天然去重，同一个用户不可能被加入两次，抽奖时用 SPOP 或 SRANDMEMBER 随机取出中奖用户，中奖结果也是一个 Set，可以自然保证不重复中奖。
另一个经典用法是“共同好友”。对两个人的好友 Set 执行 SINTER，直接就得到共同好友列表。这种集合运算如果放数据库里做，SQL 要写半天；在 Redis 里一条命令就搞定，性能还好。
3.5 ZSet：排行榜与延时队列
ZSet 在 Set 的基础上给每个成员附加了一个 score（分数），按分数自动排序。这是实现排行榜最方便的数据结构。
常用命令：
ZADD key score member：添加成员及分数，如果成员已存在则更新分数。ZRANGE key start stop：按分数从低到高返回指定区间内的成员。ZREVRANGE key start stop：按分数从高到低返回，排行榜基本都靠它。ZRANGEBYSCORE key min max：按分数范围返回成员。ZREM key member：删除成员。ZCARD key：获取成员数量。ZSCORE key member：获取成员的分数。ZINCRBY key increment member：给成员分数增加指定值。ZRANK key member：获取成员排名（从 0 开始）。ZREVRANK key member：获取成员逆序排名。
排行榜场景很典型。游戏玩家的积分排行，主播的热度排行，都离不开 ZSet。更妙的是 ZSet 还能做“滑动窗口”和“延时队列”。比如用当前时间戳作为 score，把任务丢进 ZSet，然后定期用ZRANGEBYSCORE key -inf now取出已经到期的任务，处理后再 ZREM 掉，就实现了一个延时队列。
要注意 ZSet 的底层结构是跳跃表加哈希表。跳跃表保证了分数排序和区间查询的高效，哈希表保证了成员查找的 O(1)。理解这一点，就能明白为什么 ZSet 既能做排序又能做去重。
4. 生产环境必会的运维与排查命令
4.1 DBSIZE、INFO 和 MONITOR 的使用时机
在 Linux 上排查 Redis 问题，最先要掌握的就是这几个命令：
DBSIZE：返回当前数据库的 key 数量，这个命令能快速判断 key 是否有暴涨或清空的情况。INFO：返回 Redis 服务端的运行信息，按 section 分组：server、clients、memory、persistence、stats、replication、cpu、cluster 等。
上面是我最常用的排查顺序：先看 DBSIZE 有没有异常波动，再 INFO memory 看内存有没有飙升，再 INFO clients 看连接数有没有异常。如果发现内存增长很快但 DBSIZE 变化不大，可能是某个大 key 在膨胀，这时就用 SCAN 去定位。
INFO 的详细用法：
INFO memory INFO clients INFO stats INFO replication这些可以只查看对应分类的信息，不用全量输出，输出更直观、节省带宽。
MONITOR 命令用来实时打印 Redis 收到的每条命令，非常适合在开发环境调试，但在生产环境用 MONITOR 要非常谨慎。它会持续输出所有命令，导致主线程性能下降，所以生产环境如果要排查，一般用短时间快速抓取，立刻Ctrl + C退出。
4.2 持久化命令：SAVE、BGSAVE 与 BGREWRITEAOF
Redis 持久化有 RDB 和 AOF 两种方式。RDB 是内存快照，AOF 是命令追加日志。常用命令：
SAVE：同步执行 RDB 快照，会阻塞主线程，生产环境绝不能手动执行。BGSAVE：后台异步执行 RDB 快照，不阻塞主线程，手动备份时用这个。LASTSAVE：查看最近一次成功生成 RDB 快照的时间戳。BGREWRITEAOF：后台重写 AOF 文件，可以用来压缩 AOF 体积。
手动备份的时候，我习惯用 BGSAVE，然后检查日志确认备份成功。注意 BGSAVE 过程中如果再执行 BGREWRITEAOF，Redis 会等到当前 BGSAVE 完成后才执行，避免两个后台任务同时跑导致磁盘 IO 压力过大。
AOF 在 Redis 7 之前可能同时存在 RDB 和 AOF 两种格式的文件。Redis 7 之后推出了混合持久化，AOF 文件头部是 RDB 快照，后面是增量命令，兼顾了重启速度和数据安全。
4.3 客户端与连接管理命令
有时候我们会发现 Redis 的 maxclients 配置是 10000，但连接数已经到了上限，服务无法接受新连接。这时就要看是哪些客户端占满了连接。
常用命令：
CLIENT LIST：列出所有客户端连接信息，包括 ID、地址、连接名、最后交互时间等。CLIENT INFO：查看当前连接的信息。CLIENT SETNAME name：给当前连接设置名称，方便在 CLIENT LIST 里区分用途。CLIENT KILL addr:port：杀掉指定地址的连接。CLIENT PAUSE timeout：暂停所有客户端写入操作一段时间，一般用于主从切换时的数据对齐。
CLIENT LIST 输出里有一个字段叫omem，表示输出缓冲区内存占用。如果某个客户端 omem 很大，说明它消费不急或者干脆不消费，这可能导致 Redis 内存被输出缓冲区吃光。遇到这种情况，果断用 CLIENT KILL 断开它。
用 CLIENT KILL 的关键是定位准确，一般先 CLIENT LIST 找到异常连接的地址，再执行CLIENT KILL ip:port。也可以按 ID 杀：
CLIENT KILL ID 12345杀掉 LUA 脚本的慢客户端、不可靠的订阅连接，这是运维日常里比较高频的干预手段。
4.4 CONFIG 命令的动态配置技巧
Redis 的配置有两种：一是配置文件里的静态配置，二是运行时通过 CONFIG 命令动态修改。CONFIG 命令能解决很多线上问题而不需要重启。
# 查看配置项 CONFIG GET maxmemory CONFIG GET save # 修改配置项 CONFIG SET maxmemory 2gb CONFIG SET maxmemory-policy allkeys-lru注意 CONFIG SET 修改的配置在重启后会丢失，除非执行 CONFIG REWRITE 把当前配置写回配置文件。
CONFIG REWRITE这个命令会把当前运行时配置同步到 redis.conf 文件里，避免重启后配置回退。
还有一个很实用的配置项：CONFIG SET requirepass可以动态修改密码，不用改配置文件再重启。虽然生产环境一般建议用配置文件维护密码，但紧急情况下动态修改也能应急。
5. 脚本、事务与发布订阅：进阶命令的典型应用
5.1 Lua 脚本：原子性的利器
Redis 从 2.6 版本开始支持 Lua 脚本。通过 EVAL 命令执行 Lua 脚本，Redis 会保证脚本内的所有命令原子性执行，执行期间不会被其他命令插入。
实际开发中，比较典型的需求是“扣减库存并判断结果”。如果不使用 Lua，就需要先 GET 再判断再 SET，三步之间可能存在并发问题。用 Lua 脚本就能一步完成：
local stock = tonumber(redis.call('GET', KEYS[1])) if stock > 0 then redis.call('DECR', KEYS[1]) return 1 end return 0调用方式：
redis-cli --eval stock.lua product:10001 ,或者直接在命令行：
EVAL "local stock = tonumber(redis.call('GET', KEYS[1])); if stock > 0 then redis.call('DECR', KEYS[1]); return 1; end; return 0" 1 product:10001Lua 脚本在 Redis 里使用广泛，分布式限流、分布式锁、批量取数据再写数据，这些需要原子性保证的复合操作，用 Lua 都比拼多个命令更可靠。
5.2 MULTI/EXEC 事务：乐观锁的 Watch 机制
Redis 的事务命令是 MULTI、EXEC、DISCARD 和 WATCH。它和我们熟悉的数据库事务不太一样，Redis 事务不保证原子性回滚，只保证命令按顺序执行，不会被其他客户端的命令插入。
MULTI SET key1 value1 INCR counter EXEC如果中间某条命令语法错误，整个事务会拒绝执行；但如果某条命令在运行时报错（比如对 String 类型的 key 做 LPUSH），事务还是会继续执行后面的命令，不会回滚。这与关系型数据库的事务行为有本质区别，用的时候要有预期。
WATCH 命令可以实现乐观锁。用法是在事务执行前 WATCH 一个 key，如果事务执行前这个 key 被其他客户端修改了，EXEC 会返回 nil，事务被取消。
典型场景是“更新前检查版本号”。这个机制在并发控制上还是有一定用武之地的，不过现在很多团队已经用 Lua 脚本替代了事务方案，因为 Lua 更精简、可控性更好。
5.3 发布订阅与 Stream 的取舍
Redis 的发布订阅是一组轻量级命令：
SUBSCRIBE channel：订阅一个频道。PUBLISH channel message：向频道发布消息。UNSUBSCRIBE channel：退订。PSUBSCRIBE pattern：按模式订阅，支持通配符。
发布订阅模式适合做简单的消息广播，比如在多个服务实例间同步配置变更通知。但要注意 PUB/SUB 的消息不持久化，如果订阅者不在线，消息就直接丢了，没有堆积能力。所以它更像个“即时通信”工具，不适合作为可靠的消息传递方案。
如果需要可靠消息，用 Redis Stream。Stream 是 Redis 5.0 引入的数据类型，支持消息持久化、消费者组、消息确认机制。常用命令：XADD、XRANGE、XREAD、XGROUP、XACK。不过说实话，如果项目已经接入了专业消息队列（如 Kafka、RocketMQ），一般情况下没必要用 Stream 替代，除非你想减少组件数量，Redis 本来就有的情况下顺手用 Stream 足够。
6. 面试与日常踩坑中的命令实战
6.1 缓存穿透、击穿、雪崩场景下的命令运用
这三个词在 Redis 面试中几乎必问，但很多人只是背概念，不知道背后的命令操作和排查方式。
缓存穿透：请求的数据在缓存和数据库里都不存在，导致请求每次都打到数据库。典型解法是缓存空值，即对不存在的 key 也设置一个空值并加上较短的过期时间，比如 60 秒。命令就是先SET key "" EX 60，下次请求来了发现 key 存在且值为空，直接返回。
也可以用布隆过滤器。布隆过滤器不在 Redis 原生命令里，但 Redis 4.0 以后可以通过模块支持，命令类似BF.ADD、BF.EXISTS。
缓存击穿：某一个热点 key 过期，瞬间大量请求穿透到数据库。解法是加分布式锁，让只有一个请求去 DB 查数据，其他请求等待或者取旧值。Redis 分布式锁的命令基础就是 SETNX 加过期时间、DEL 释放锁。
缓存雪崩：大量 key 在同一时间过期，导致请求全部落到数据库。解法是过期时间加随机偏移，比如EXPIRE key 3600 + random(0, 300)。另外还可以做多级缓存或者把热点数据设置成永不过期，由后台任务定期更新。
6.2 分布式锁的常见实现：SETNX 的正确用法
分布式锁应该是 Redis 命令应用里被问得最多的一个场景。简单实现如下：
SET lock:order:10001 uuid_value NX EX 10这里 NX 保证只有 key 不存在时才能设置成功，EX 10 保证锁的最大持有时间是 10 秒。将流程拆开看：第一个线程成功设置，其他线程设置失败，就拿到了锁，处理完业务后用 DEL 释放，这就完成了一个最基本的分布式锁。
但这里有一个非常经典的坑：如果业务执行时间超过了锁的过期时间，锁自动释放，第二个线程又获取到锁，第一个线程执行完后删除的是第二个线程的锁，导致锁失效。解决办法有两个：
从服务端解决，用 Lua 脚本在删除锁之前判断 value 是否是自己设置的：
if redis.call('GET', KEYS[1]) == ARGV[1] then return redis.call('DEL', KEYS[1]) else return 0 end这样在释放锁之前先检查值，确保只能删除自己的锁。这也是生产环境分布式锁的基础实现方式。
如果对可靠性要求极高，直接用 Redisson，它的看门狗机制会自动续期，避免锁过期导致的问题。这个已经是业界标准做法了。
6.3 大 key 与热 key 的排查处理
大 key 和热 key 是 Redis 运维中两个最常见的问题，而且都可以通过命令层面做初步定位。
大 key 指的是单个 key 的 value 过大或元素过多。例如一个包含几百万元素的 Set，或者一个几十 MB 的 String。大 key 会导致两种典型问题：一是访问慢，二是删除或迁移时阻塞主线程。排查方式：
redis-cli --bigkeys这个命令会自动扫描所有 key，按类型统计最大的 key。注意它在扫描过程中是用 SCAN 实现的，不会阻塞主线程，但会占用一定 CPU，建议在低峰期执行。
定位到具体的大 key 之后，如果是 String 类型，直接用STRLEN key查看长度；如果是集合类型，用LLEN key、SCARD key、HLEN key、ZCARD key查看元素数量。处理方式一般是拆分 key、压缩 value、异步删除（UNLINK）。
热 key 指短时间内被大量访问的 key。排查热 key 可以先看INFO stats里的键空间命中率，再用 MONITOR 短时间抓取命令频率。也可以启用 Redis 的 hotkey 分析功能。
如果热 key 导致单实例 CPU 过高，解决思路一般是本地缓存 + 读写分离 + key 拆分。本地缓存是最高效的，把热点数据在业务进程内缓存一份，批量请求就不需要打 Redis 了。
6.4 Linux 下 Redis 命令的实用技巧
最后分享几个 Linux 环境下 Redis 命令的使用技巧，都是我日常用下来很顺手的小习惯。
第一个是单行执行命令。在 shell 脚本里，经常需要非交互式执行 Redis 命令：
redis-cli -h 127.0.0.1 -p 6379 -a yourpassword GET user:10001如果不加密码就会报NOAUTH Authentication required。密码直接写在命令行会出现在进程列表里，有泄露风险，更安全的做法是配置文件里指定密码并设置好权限，或者用REDISCLI_AUTH环境变量。
第二个是批量操作。比如清理所有session:前缀的 key：
redis-cli --scan --pattern 'session:*' | xargs -L 100 redis-cli DEL这里-L 100表示每 100 个参数执行一次 DEL，避免命令行参数过长。
第三个是查看慢日志。Redis 默认会记录超过阈值的慢命令：
SLOWLOG GET SLOWLOG LEN如果发现大量慢命令，可以用CONFIG SET slowlog-log-slower-than调整阈值，默认是 10000 微秒，单位是微秒。排查性能问题，慢日志是非常可靠的参考。
第四个是redis-cli --stat，实时查看 Redis 的每秒处理命令数、内存变化等，比较直观。
用这些技巧，我们日常常见的 Redis 问题，大部分在 Linux 命令行就可以定位和处理了。
我在实际操作中最深的感受是，Redis 命令本身并不难，难的是在合适的场景选对命令，以及知道哪些命令在生产环境有坑。把这些基础打牢，遇到问题时先想清楚当前场景的数据结构本质，再动手操作，才是长期稳定的使用之道。
