Redis 慢查詢分析與優化
參考書籍 ： https://weread.qq.com/web/reader/d5432be0813ab98b6g0133f5kd8232f00235d82c8d161fb2
以下從配置參數、耗時細分、分析工具、優化策略四個維度深入解析 Redis 慢查詢問題，結合實戰調優建議，幫助開發者精準定位并優化性能瓶頸。
一、慢查詢核心配置參數
Redis 慢查詢功能通過兩個關鍵參數控制，直接影響日志記錄范圍和存儲容量：
-
?
slowlog-log-slower-than?-
功能：設定命令執行時間的閾值（單位：微秒），超過此值的命令會被記錄。
-
默認值：10000 微秒（10 毫秒），建議高并發場景調整為 1000 微秒（1 毫秒） 。
-
特殊值：
- ?
0?：記錄所有命令（調試用）。 - 負值：禁用慢查詢日志。
- ?
-
-
??
slowlog-max-len?- 功能：定義慢查詢日志列表的最大長度（先進先出隊列）。
- 默認值：128 條，生產環境建議調至 1000 條以上，避免關鍵日志被覆蓋。
配置示例：
# 動態設置（臨時生效）
CONFIG SET slowlog-log-slower-than 1000
CONFIG SET slowlog-max-len 1000 # 持久化到配置文件（需重啟）
slowlog-log-slower-than 1000
slowlog-max-len 1000
二、耗時細分與瓶頸定位
Redis 命令執行全流程耗時可拆分為以下階段：
-
網絡傳輸（客戶端到服務端）：
- 網絡延遲或丟包可能導致客戶端感知的耗時增加，但不記錄在慢查詢日志中。
- 排查工具：
ping?、traceroute? 或監控工具（如 Prometheus）。
-
命令排隊（Redis 內部隊列）：
- 單線程架構下，若并發請求過高，命令需排隊等待執行。
- 排隊時間不納入慢查詢統計，但可能導致客戶端超時。
-
命令執行（核心耗時）：
- 實際執行命令的耗時，由慢查詢日志的
duration? 字段記錄（單位：微秒）。 - 高復雜度命令（如
KEYS?、SORT?）或 BigKey 操作是主要瓶頸。
- 實際執行命令的耗時，由慢查詢日志的
-
結果返回（服務端到客戶端）：
- 網絡傳輸時間同樣不計入慢查詢日志，但可能影響客戶端體驗。
三、慢查詢分析工具
-
內置命令：
-
**
SLOWLOG GET [n]?**：獲取最近 n 條慢查詢日志，含時間戳、耗時、具體命令。
127.0.0.1:6379> SLOWLOG GET 2 1) 1) (integer) 12345 # 日志ID 2) (integer) 1680000000 # 時間戳 3) (integer) 15000 # 耗時（微秒） 4) 1) "SORT" # 命令及參數 2) "mylist" -
**
SLOWLOG LEN?**：查看當前慢查詢日志數量。 -
**
SLOWLOG RESET?**：清空日志列表。
-
-
監控工具：
-
**
INFO COMMANDSTATS?**：統計所有命令的執行次數和總耗時，定位高頻耗時命令。
參數介紹:
截圖中每一項均以
cmdstat_<命令名>? 開頭，代表對應 Redis 命令的執行統計信息，各參數含義如下：參數名 含義 ? calls?該命令的總執行次數。 ? usec?該命令所有執行耗時的總和（單位：微秒，μs）。 ? usec_per_call?該命令的平均執行時間（單位：微秒，μs），即 usec ÷ calls?。? rejected_calls?該命令被拒絕執行的次數（如權限不足、命令被禁用等情況）。 ? failed_calls?該命令執行過程中失敗的次數（如參數錯誤、執行邏輯異常等）。 以
cmdstat_ttl:calls=304,usec=3064,usec_per_call=10.08,rejected_calls=1,failed_calls=0? 為例：- ?
TTL? 命令共執行304? 次，總耗時3064? 微秒，平均每次耗時10.08? 微秒，被拒絕執行1? 次，執行失敗0? 次。
其他項（如
cmdstat_auth?、cmdstat_set? 等）均遵循此格式，分別對應各自命令的統計數據，可據此分析命令的執行頻率、性能及異常情況。 - ?
-
**
MONITOR?**：實時捕獲所有命令（慎用，可能引發性能問題）。 -
第三方工具：Prometheus + Grafana 實現可視化監控。 后續研究
-
四、優化策略與實戰建議
-
規避高復雜度命令：
-
替代方案：
- 用
SCAN? 代替KEYS? 遍歷鍵。 - 客戶端實現排序，避免
SORT? 命令處理大數據集。
- 用
-
分頁處理：對大型集合使用
LRANGE? 分批次獲取數據。
-
-
BigKey 治理：
-
拆分存儲：將大 Hash/List 拆分為多個子鍵（如
user:1001:logs_part1?）。 -
漸進式刪除：通過 Lua 腳本分批次刪除 BigKey，避免阻塞。
-- 分批次刪除大列表 local key = KEYS[1] for i = 1, 1000 do redis.call("LPOP", key) end
-
-
配置調優：
- 內存管理：設置
maxmemory? 和淘汰策略（如allkeys-lru?）。 - 集群分片：使用 Redis Cluster 分散負載，緩解單節點壓力。
- 內存管理：設置
五、調優最佳實踐
-
定期日志分析：
- 每日檢查慢查詢日志，識別高頻耗時命令。
- 結合
INFO COMMANDSTATS? 驗證優化效果。
-
閾值動態調整：
- 業務高峰期臨時降低
slowlog-log-slower-than?（如 500 微秒），捕捉潛在問題。
- 業務高峰期臨時降低
-
日志持久化：
- 定期將慢查詢日志導出到外部存儲（如 Elasticsearch），便于長期分析。
總結
通過合理配置 slowlog-log-slower-than? 和 slowlog-max-len?，結合 SLOWLOG GET? 和監控工具，可精準定位 Redis 性能瓶頸。優化核心在于規避高復雜度命令、治理 BigKey、動態調整配置及利用集群技術。定期分析日志與監控數據，是保障 Redis 高性能運行的關鍵。
?
)
