大数据-44 Redis 慢查询日志详解与性能优化实战指南

点一下关注吧！！！非常感谢！！持续更新！！！

🚀 AI篇持续更新中！（长期更新）

AI炼丹日志-30-新发布【1T 万亿】参数量大模型！Kimi‑K2开源大模型解读与实践，持续打造实用AI工具指南！📐🤖

💻 Java篇正式开启！（300篇）

目前2025年07月16日更新到： Java-74 深入浅出 RPC Dubbo Admin可视化管理安装使用源码编译、Docker启动 MyBatis 已完结，Spring 已完结，Nginx已完结，Tomcat已完结，分布式服务正在更新！深入浅出助你打牢基础！

📊 大数据板块已完成多项干货更新（300篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！ 大数据-278 Spark MLib - 基础介绍机器学习算法梯度提升树 GBDT案例详解

Redis 提供了类似 MySQL 的慢查询日志机制，用于记录执行时间超过指定阈值的命令，帮助开发者分析性能瓶颈与系统异常。通过配置 slowlog-log-slower-than 和 slowlog-max-len，可以精准控制记录策略。运维人员可使用 SLOWLOG GET 查看日志，快速定位慢命令及其影响。为进一步优化性能，可采取数据结构精简、避免大Key与全量命令、合理持久化配置、使用Pipeline批量操作等措施。此外，Redis 还支持 MONITOR 实时命令跟踪（不建议用于生产）及接入 Grafana + Prometheus + RedisExporter 的可视化监控系统，实现慢查询检测、告警与资源监控的闭环优化。

章节内容

上节完成了的内容如下：

Redis通过Lua功能进行扩展
Lua下载安装
Lua在Redis中的使用案例（多个）

Redis 慢查询详解

慢查询概念

MySQL 中有完善的慢查询日志机制，在 Redis 中同样提供了慢查询日志功能。Redis 慢查询日志用于记录执行时间超过指定阈值的命令请求，帮助开发人员和运维人员监控和优化 Redis 查询性能。

慢查询实现机制

Redis 使用一个先进先出(FIFO)的列表来存储慢查询日志，这种实现方式有以下几个特点：

采用固定长度的队列结构
当新记录超过最大长度时，最旧的记录会被自动移除
查询效率高，O(1)时间复杂度

慢查询配置参数

在 redis.conf 配置文件中，有两个关键参数控制慢查询日志的行为：

slowlog-log-slower-than
- 单位：微秒(1秒=1000000微秒)
- 作用：设置命令执行时间的阈值
- 取值说明：
  - 0：记录所有命令
  - <0：不记录任何命令
  - 0：只记录执行时间超过该值的命令
- 默认值：10000微秒(10毫秒)
- 生产环境建议：根据业务特点调整，通常设置为1-10毫秒
slowlog-max-len
- 作用：设置慢查询日志的最大条数
- 默认值：128条
- 建议值：根据内存情况和监控需求调整，通常设置为1000-10000条

配置示例

shell 复制代码

# 记录执行时间超过5毫秒的命令
slowlog-log-slower-than 5000

# 保留最近1000条慢查询记录  
slowlog-max-len 1000

慢查询查看方法

可以通过 Redis 命令行工具查看慢查询日志：

shell 复制代码

SLOWLOG GET [n]  # 获取最近的n条慢查询记录
SLOWLOG LEN      # 获取当前慢查询日志条数
SLOWLOG RESET    # 清空慢查询日志

应用场景

性能问题排查：当发现 Redis 响应变慢时，检查慢查询日志找出耗时命令
命令优化：识别需要优化的热点命令
容量规划：分析命令执行时间分布，为扩容提供依据
异常监控：通过定期检查慢查询日志发现异常查询模式

查询日志

为了方便测试，可以通过暂时设置的方式，将检查的阈值调低。

shell 复制代码

config set slowlog-log-slower-than 0
config set slowlog-max-len 2

此时我们的操作基本上都会变成慢操作：

shell 复制代码

set name wzk
set age 123
get name
get age

我们查看慢日志内容：

shell 复制代码

slowlog get

日志可以用来解决以下问题：

问题诊断：当系统或应用程序出现问题时，日志提供的信息，帮助开发人员追踪和定位问题的根本原因。
性能优化：通过分析日志数据，可以了解系统的性能瓶颈和潜在问题，并采取相应的措施来优化系统的性能。

Redis性能优化：定位与处理慢查询

慢查询定位与分析

使用slowlog get命令获取Redis执行较慢的命令日志
分析日志中的关键信息：执行时间、命令内容、发生时间等
重点关注执行时间超过10ms的命令（可根据业务需求调整阈值）

具体优化措施

数据结构优化

精简键值设计：
- 使用简短且有意义的Key名称（如user:1001:profile而非user_profile_information_1001）
- 对于Value数据：
  - 优先使用int类型（如存储数字1000而非字符串"1000"）
  - 避免冗余数据存储
避免危险操作：
- 禁止使用keys *这种全量扫描命令（替代方案：使用SCAN命令分批次获取）
- 谨慎使用hgetall（替代方案：使用hmget获取指定字段或hscan分批次获取）
大Key处理：
- 将大Value拆分为多个小Value（如将包含1000个元素的List拆分为10个100元素的List）
- 使用分页查询代替全量获取

配置优化

持久化策略 ：
- 将RDB模式转换为AOF模式
- RDB的潜在问题：
  - 执行fork操作创建子进程可能阻塞主线程
  - 在数据量大的情况下fork操作耗时较长
- AOF优势：
  - 以追加方式记录操作日志
  - 可配置不同的fsync策略平衡性能与安全性

高效操作技巧

管道(Pipeline)技术：
- 适用场景：需要批量执行多个命令时
- 实现原理：将多个命令打包一次性发送，减少网络往返时间
- 示例：批量设置100个键值对时，管道可提升10倍以上性能
合理使用Hash：
- 适合存储对象属性（如用户信息：hmset user:1001 name "John" age 30）
- 相比多个String键存储，Hash能减少内存使用和网络开销

资源管理

内存限制 ：
- 设置maxmemory参数限制Redis最大内存使用量
- 配合maxmemory-policy配置内存淘汰策略
- 好处：
  - 避免使用swap分区导致性能急剧下降
  - 防止OOM(Out Of Memory)错误导致服务崩溃
  - 推荐设置为物理内存的3/4，留出部分内存供系统使用

监控与持续优化

定期检查slowlog，分析新的性能瓶颈
使用info memory监控内存使用情况
对复杂查询考虑使用Redis Lua脚本优化
在高并发场景下，考虑使用Redis集群分散压力

监视器 (MONITOR)

功能概述

Redis 的 MONITOR 命令允许客户端实时监控服务器接收和处理的所有命令请求。当一个客户端执行 MONITOR 命令后，它会变成一个监视器，持续接收并显示服务器执行的每个命令的详细信息。

工作原理

执行 MONITOR 命令：客户端连接后只需发送简单的 MONITOR 命令即可进入监视模式。
服务器行为变化 ：
- 对于普通客户端，服务器正常处理命令请求
- 对于监视器客户端，服务器会将所有接收到的命令转发给它们
信息格式 ：每条监控信息包含以下内容：
- 时间戳（精确到微秒）
- 客户端连接的唯一标识符
- 客户端来源 IP 和端口
- 执行的 Redis 命令及其参数

使用示例

redis 复制代码

127.0.0.1:6379> MONITOR
OK
1609459200.123456 [0 127.0.0.1:52345] "SET" "foo" "bar"
1609459200.234567 [1 192.168.1.100:62834] "GET" "foo"

应用场景

调试与开发：实时观察所有客户端命令，帮助诊断问题
性能分析：监控命令执行频率和模式
安全审计：记录所有操作用于安全审查

注意事项

性能影响：MONITOR 会显著增加服务器负载，不应在生产环境长期使用
信息量：高流量环境下会产生大量输出，可能导致网络拥塞
权限控制：建议限制 MONITOR 命令的使用权限

关闭监视器

要退出监视模式，客户端可以：

断开与服务器的连接
发送 QUIT 命令
或等待连接超时

替代方案

对于生产环境，考虑使用更轻量的方案：

SLOWLOG 获取慢查询日志
配置文件中设置日志级别
使用 Redis 的 Pub/Sub 机制实现定制化监控

客户端1

shell 复制代码

./redis-cli
monitor

客户端2

shell 复制代码

./redis-cli
set name:001 wzk
set name:002 kangkang
set age:001 12
set age:002 33

Redis 监控平台方案详解

Redis作为高性能的内存数据库，在生产环境中需要全面的监控来确保其稳定性和性能。以下是几种主流的Redis监控解决方案：

1. Grafana

Grafana是一个开箱即用的可视化工具，具有以下特点：

功能齐全的度量仪表盘：提供丰富的预置Redis监控面板模板
灵活的图形编辑器：支持自定义图表样式和布局
多数据源支持：可同时接入Prometheus、InfluxDB等多种数据源
告警功能：支持设置阈值告警并通过邮件、Slack等渠道通知

典型应用场景：需要快速搭建可视化监控系统，且对UI美观度要求较高的场景。

2. Prometheus

Prometheus是一个开源的监控系统，专门用于记录实时指标：

数据采集机制：通过HTTP协议主动拉取目标上的指标数据
本地时序数据库：高性能的TSDB存储方案
强大的查询语言：PromQL提供灵活的数据查询能力
多维数据模型：支持通过标签进行多维度数据聚合

部署架构：Prometheus Server + RedisExporter + Grafana（可选）

3. RedisExporter

RedisExporter是专为Prometheus设计的Redis指标导出工具：

指标收集：采集Redis的关键性能指标（内存使用、命令统计、连接数等）
指标转换：将Redis的INFO命令输出转换为Prometheus格式
轻量级：作为独立的守护进程运行，资源消耗低

配置示例：

ini 复制代码

./redis_exporter \
  -redis.addr=redis://localhost:6379 \
  -web.listen-address=:9121

4. 综合监控方案

推荐的完整监控架构：

复制代码

Redis实例 → RedisExporter → Prometheus → Grafana

这种组合提供了：

数据采集（RedisExporter）
数据存储和告警（Prometheus）
可视化展示（Grafana）

典型监控指标包括：

内存使用率
命令执行次数
连接数
键空间使用情况
持久化状态
复制状态（主从架构下）