SLOWLOG GET 导出需经结构化转换：用 redis-cli SLOWLOG GET N | jq -r '... ' 生成 CSV，字段含 ID、时间戳、耗时(μs)、命令名、参数、客户端地址、DB 编号；参数中换行/引号已转义，避免解析错位。
怎么用 SLOWLOG GET 导出可分析的原始数据
直接在 redis-cli 里执行 SLOWLOG GET 返回的是 Redis 协议格式（带嵌套数组），不适合 Excel 或 Python 直接处理。你需要先转成结构化文本，比如 CSV 或 JSON。
推荐用这个一行命令导出最近 1000 条（注意：必须连到每个节点单独执行）：
redis-cli -h node1 -p 7001 SLOWLOG GET 1000 | jq -r '.[] | "(.["1"]|tonumber),(.["2"]|tonumber),(.["3"]|tonumber),(.["4"][0]|tostring),(.["4"][1:]|join(" ")|gsub("
";" ")|gsub(""";"\"")),(.["5"]|tostring),(.["6"]|tostring)"' > slowlog_node1.csv-
jq是必须的，没装就先brew install jq（macOS）或apt install jq（Linux） - 字段顺序是：
ID,时间戳,耗时(μs),命令名,参数字符串,客户端地址,数据库编号 - 参数字符串里换行和引号会被转义，避免 CSV 解析错位
- 别漏掉
-h和-p——集群里连错节点，导出来的日志跟业务完全对不上
为什么不能只看“耗时最长”的那几条命令
真实业务中，单次耗时 500ms 的 HGETALL 很吓人，但可能一天只发生 3 次；而平均耗时 8ms 的 INCR 每秒调用 2000 次，累积 CPU 占用反而更高。慢查询日志本身不带频次统计，必须补上聚合维度。
导出 CSV 后，用 pandas 做简单聚类（Python 示例）：
import pandas as pd
df = pd.read_csv("slowlog_node1.csv", names=["id","ts","us","cmd","args","client","db"])
# 按命令 + 参数模式粗粒度分组（例如把 "user:1001" "user:1002" 都归为 "user:*"）
df["pattern"] = df["args"].str.replace(r":d+", ":*", regex=True).str.slice(0, 64)
grouped = df.groupby(["cmd", "pattern"]).agg({"us": ["count", "mean", "max"], "id": "count"}).round(1)
print(grouped.nlargest(10, ("us", "count")))- 关键不是
max(us)，而是count高 +mean(us)超过 5ms 的组合 -
args截断到 64 字符，防止 key 太长导致内存爆炸或分组散列失效 - 如果发现大量
pattern是"*"（比如KEYS *），立刻停用 —— 这是集群级危险操作
如何关联到具体业务代码位置
SLOWLOG 不记录 trace_id、线程名或调用栈，但你可以通过两个线索反查：
第一，用客户端 IP + 端口（client 字段）去查服务日志。例如某条慢查询显示 "10.20.30.40:56789"，就在对应应用的 access.log 或 debug 日志里搜 56789，通常能定位到 Controller 或 Service 方法名。
第二，对高频慢命令加监控埋点。比如在 Java 里封装一层 Jedis.execute()，记录：
- 调用方类名 + 方法名（用
Thread.currentThread().getStackTrace()抽最上层业务栈） - 实际执行的完整命令（含所有参数）
- 是否在事务/ pipeline 内
这样下次再看到 HMGET user:123 profile:name profile:avatar 耗时高，就能直接跳转到 UserProfileService.getBasicInfo() 方法里看有没有缓存穿透或 N+1 查询。
聚类后仍无法定位根因？检查这三处隐藏配置
导出、分组、关联都做了，但还是找不到为什么某个 ZRANGE 总是慢——问题往往不在命令本身，而在环境配置：
-
slowlog-log-slower-than被设成0（记录所有命令），导致日志里混入大量本不该算“慢”的短命令，稀释了真瓶颈。确认当前值：CONFIG GET slowlog-log-slower-than -
latency-monitor-threshold没开（默认 0），无法捕获事件循环卡顿。它和SLOWLOG是互补的：前者抓 Redis 内部卡顿（如 AOF fsync），后者只抓命令执行耗时。建议设为100（毫秒）并用LATENCY LATEST辅助验证 - 客户端用了
MGET但 key 分布在多个 slot，触发了跨节点重定向（-MOVED）。这种请求在SLOWLOG里显示为单次长耗时，实际是多次网络往返叠加。用CLUSTER KEYSLOT {key}检查 key 分布是否集中
真正难的不是导出和聚类，而是把一条 SLOWLOG 记录，还原成「哪个服务、哪个方法、在什么上下文、调用了什么语义的命令、为什么这次特别慢」——这中间每一步都可能断链。别依赖自动工具全链路追踪，手动交叉验证仍是最快路径。
