Redis常用检查命令有哪些？

Redis作为高性能的内存数据库,其命令行的检查命令是运维和开发人员日常工作中不可或缺的工具，通过这些命令可以快速了解Redis的运行状态、内存使用、客户端连接、持久化情况等关键信息，以下从多个维度详细介绍Redis的常用检查命令。

在基本信息检查方面,INFO命令是最核心的工具，它返回Redis服务器的各种信息和统计，通过INFO [section]可以指定查看特定部分的信息，例如INFO server返回服务器基本信息（如版本号、运行时长、进程ID），INFO memory展示内存使用详情（如已用内存、峰值内存、内存碎片率），INFO clients显示客户端连接数（包括连接的客户端地址、名称、命令执行数等），INFO stats提供通用统计信息（如总命令数、连接数限制、拒绝连接数），若不指定section，默认返回所有信息，但输出内容较长，建议按需查询。

内存使用检查是Redis优化的重点,除INFO memory外，MEMORY USAGE key [SAMPLES count]命令可精确查看某个键的内存占用，例如MEMORY USAGE mylist返回列表键mylist的内存大小，添加SAMPLES参数可通过采样估算复杂类型（如哈希、集合）的内存占用，减少对性能的影响。MEMORY STATS则以更详细的方式返回内存分配器的统计信息，包括已用内存、峰值内存、内存碎片率等，帮助判断内存是否存在泄漏或碎片化问题。DBSIZE命令返回当前数据库的键数量，快速了解数据规模。

客户端连接检查对于排查性能瓶颈和异常连接至关重要。CLIENT LIST列出所有连接到Redis的客户端信息，包括客户端ID、地址、端口、连接时间、最后执行命令、缓冲区使用情况等，例如通过CLIENT LIST | grep "idle"可查看空闲连接，识别长时间占用连接的客户端。CLIENT GETNAME和CLIENT SETNAME name分别用于获取和设置客户端名称，方便标识和管理不同客户端的连接。CLIENT KILL addr:port可强制断开指定地址和端口的客户端连接，用于清理异常或恶意连接。

持久化状态检查涉及Redis数据安全。LASTSAVE返回最后一次成功执行持久化（RDB或AOF）的时间戳，通过date -d @timestamp可转换为可读时间，判断持久化是否正常执行，对于AOF持久化，INFO persistence中的aof_current_size和aof_base_size分别显示当前AOF文件大小和上次启动时的大小，aof_rewrite_in_progress和aof_rewrite_scheduled则反映AOF重写状态，帮助监控AOF重写是否卡住或延迟。BGSAVE和BGREWRITEAOF命令虽用于触发持久化，但也可通过检查后台进程状态（如INFO stats中的rdb_last_bgsave_status）判断持久化是否成功。

性能与统计检查方面,SLOWLOG [get count]用于查询慢查询日志，例如SLOWLOG get 5返回最近5条执行时间超过slowlog-log-slower-than阈值的命令，帮助定位性能瓶颈。INFO stats中的instantaneous_ops_per_sec显示每秒操作数，实时监控服务器负载；total_connections_received和rejected_connections分别记录总连接数和被拒绝的连接数，判断服务器是否达到连接数上限。

相关问答FAQs
Q1: 如何通过命令快速定位Redis中内存占用最大的键？
A1: 可以结合MEMORY USAGE命令和SCAN遍历所有键进行排序，具体步骤为：使用SCAN 0遍历所有键，对每个键执行MEMORY USAGE获取内存大小，将结果按内存占用降序排序，例如通过脚本实现：redis-cli --scan --pattern "*" | while read key; do echo "$(redis-cli MEMORY USAGE "$key") $key"; done | sort -nr | head -n 10，该命令会输出内存占用前10的键及其大小。

Q2: Redis的INFO memory中的mem_fragmentation_ratio过高或过低可能是什么原因？如何处理？
A2: mem_fragmentation_ratio是已用内存与物理内存的比值，正常范围在1.0~1.5之间，若过高（如>1.5），通常因内存碎片化（频繁分配释放不同大小内存导致），可通过重启Redis释放碎片；若过低（如<1.0），可能因Redis使用了swap（交换空间），需检查系统内存是否不足，或调整maxmemory避免Redis过度占用内存，禁用THOO淘汰策略（maxmemory-policy）也可能减少碎片，但需结合业务场景调整。