慢查询定位流程
慢查询定位是一条固定流程：从 SLOWLOG 找候选命令 → 复现并确认复杂度 → 检查数据规模（大键、大集合、元素很多的结构）→ 判断是否集中触发（后台任务、批处理、定时脚本）→ 优化命令写法或改造数据结构，最后回测确认慢条目消失。
定位步骤
| 第 1 步 | SLOWLOG 采样，确定候选命令、耗时与来源客户端 |
|---|---|
| 第 2 步 | 确认时间复杂度与实际数据规模是否匹配 |
| 第 3 步 | 检查是否集中触发，区分业务流量与后台任务 |
| 第 4 步 | 优化：换命令写法、拆数据结构、改写访问模式 |
| 第 5 步 | 回测：SLOWLOG RESET 后重跑同一业务流程 |
常见慢命令与替代思路
| 慢命令 | 问题所在 | 替代思路 |
|---|---|---|
| KEYS | 遍历整个键空间 | 改用 SCAN 分批遍历 |
| HGETALL 或 SMEMBERS 大集合 | 一次性返回全部元素 | 分批取字段，或用 HSCAN 迭代 |
| DEL 大键 | 一次性释放开销集中在主线程 | 改用 UNLINK 异步释放 |
| SORT | 排序自身开销大 | 移到应用侧排序或做预计算结果 |
| LRANGE 取全量 | 返回元素过多 | 分页读取，限制返回条数 |
取证与验证
取证与验证
redis-cli SLOWLOG GET 20 # 看候选命令与来源
redis-cli TYPE suspect:key && redis-cli MEMORY USAGE suspect:key
redis-cli HLEN suspect:key # 大集合看规模：LLEN、SCARD、ZCARD 同理
redis-cli INFO commandstats | grep -E 'cmdstat_(keys|hgetall|smembers)'
redis-cli SLOWLOG RESET # 清空后重跑流程做对照典型使用场景
- 慢日志巡检：定期把上榜命令过一遍，识别结构性写法问题
- 发布后回退定位：对比发布前后的慢命令清单
- 数据结构改造前取证：确认元素规模与单键体积
- 客户端写法审查：识别批量全量取数这类高风险调用
- 区分与后台任务相关的条目，避免误判方向
同一条命令昨天不慢今天慢，通常指向数据规模增长；先量元素个数与键体积，再决定是改命令还是拆结构。
有些条目来自后台任务或运维脚本（全量扫描、批量修复），从来源地址与命令形状就能区分，别把这类流量当成业务问题去优化