Redis 能減少資料庫重復工作，但它並非天然有利。網絡延遲、淘汰策略、序列化和外掛程式行為都可能讓它變成新的瓶頸。
“已連接”不等於健康。應該測量命中率、延遲、內存壓力以及真實應用行為。
1. 先確認 Redis 在哪裡運行
Unix Socket、本機 TCP 與遠程 Redis 的延遲差異很大。遠程緩存甚至可能比被替代的資料庫查詢更慢。
2. 檢查內存與淘汰策略
頻繁淘汰會導致性能不穩定，並讓對象還沒產生價值就被刪除。
3. 區分對象緩存與頁面緩存
對象緩存、整頁緩存和 CDN 存放的東西不同。應該清理真正擁有陳舊值的那一層。
4. 查找超大或高頻變動對象
大型 options、transients 與頻繁變化的 key 會增加內存和序列化成本。
5. 單獨測量 wp-admin
後台頁面往往會暴露匿名前台基準測試看不到的對象緩存問題。
6. 做有控制的開關對比
受控 A/B 測量比猜測更有價值。如果關閉對象緩存後目標路徑更快，應先調查原因再重新啓用。