早上打开淘宝，首页商品图唰一下全出来；而某次公司内部系统刚重启，点个用户详情页要等3秒——后台日志里全是「cache miss」。差别在哪？很多人没注意：前者用了缓存预热，后者直接裸奔上线。
缓存预热不是“提前塞数据”，而是“抢在用户前面动手”
缓存预热，说白了就是服务启动或低峰期，主动把高频访问的数据从数据库捞出来，塞进 Redis 或本地缓存里。不是等用户点开才查库、再写缓存，而是提前把“热门菜”端上桌。
比如双11前一小时，运维脚本批量把热搜前100的商品信息、店铺评分、库存状态全载入 Redis：
redis-cli -h 127.0.0.1 -p 6379 SET "item:10086:detail" "{\"name\":\"无线充电器\",\"price\":89.9,\"stock\":1245}"
redis-cli -h 127.0.0.1 -p 6379 EXPIRE "item:10086:detail" 3600这样用户一搜“充电器”，缓存直接吐结果，不用碰数据库。
命中率提升不是玄学，是可量化的
我们拿一个真实订单查询接口做了对比（QPS 1200，MySQL 8.0 + Redis 7）：
- 未预热：缓存命中率 63%，平均响应 210ms，数据库 CPU 常飙到 85%；
- 预热后（加载TOP 500订单模板+近7天活跃用户基础信息）：命中率升至 92%，平均响应压到 135ms，DB 负载回落到 40% 左右。
关键不在“全量预热”，而在“选对数据”。预热一堆没人看的冷门配置项，反而占内存、拖慢淘汰策略。
小心这三种“假预热”陷阱
① 预热完不校验：脚本跑完了，但 Redis 连接超时或 key 写错前缀，实际没写进去。上线前用 redis-cli KEYS "item:*:detail" | wc -l 快速数一数。
② 预热数据过期时间一刀切：用户资料和商品价格有效期差十倍，却都设 1 小时。结果价格变了一小时还没更新，用户看到旧价投诉了。
③ 把预热当万能膏药：缓存穿透、击穿、雪崩问题还在，光预热解决不了。比如恶意刷不存在的订单号，预热根本覆盖不到，得配布隆过滤器+空值缓存。
缓存预热不是银弹，但它确实是让缓存真正“热起来”的第一步。就像冬天开车前先热车——不是为了炫技，是让机油流到每个角落，一踩油门就响应。