SQL热点数据缓存是围绕高频访问数据识别、性能瓶颈分析与请求拦截的一整套协同机制，核心目标是防止数据库在高峰时被重复请求击穿；需通过performance_schema或pg_stat_statements等工具精准定位真热点SQL模板，并采用逻辑过期+分布式锁保障缓存一致性，结合业务语义命名、分场景预热及写热点异步化处理。
SQL热点数据缓存不是给SQL语句加个缓存开关，而是围绕“哪些数据被高频访问、为什么慢、怎么提前拦住请求”展开的一整套协同动作。核心目标很实在：不让数据库在高峰时刻被同一行、同一条件反复打穿。
从执行频率里揪出真热点
别靠感觉猜“哪个商品火”，得用数据说话。MySQL可开 performance_schema 或启用 slow log + general log 配合标准化（比如把 WHERE id = 123 和 WHERE id = 456 归为 WHERE id = ?）；PostgreSQL 直接查 pg_stat_statements 视图，筛出 QPS > 500 且缓存命中率突降的 SQL 模板。这类 SQL 对应的表+条件组合，才是值得投入保护的真热点。
缓存层必须带“脑子”，不能只靠过期
对确认的热点 key，放弃简单设 TTL 的做法：
- 改用逻辑过期：value 里嵌入
{"data": "...", "expire_at": 1741320000}，读时校验时间戳，过期则触发异步更新，仍返回旧值 - 强一致性场景补分布式锁：检查到逻辑过期后，用
SET hot_user:123_lock "token" NX EX 5争锁，抢到才查库写缓存 - key 命名带业务语义，比如
user:profile:123，别用sql:select*fromuserswhereid=123—— 后者没法做 TTL 管理，也无法主动失效
预热不是“开机就刷一遍”，而是精准卡点
预热要分两类来操作：
- 确定性热点（如每日 10:00 开启的秒杀），在过期前 2 分钟由定时任务主动刷新缓存
- 突发性热点（如热搜话题飙升），靠监控告警驱动：一旦发现某 key 的 miss rate 1 分钟内升到 30%，立刻触发轻量预热脚本
- 预热本身要限流，避免反向压垮数据库；优先走覆盖索引查询（如
SELECT id FROM orders WHERE status = 'paid' ORDER BY created_at DESC LIMIT 100），不查SELECT *
写热点必须绕开单行锁瓶颈
读热点靠缓存能缓解，写热点却会卡在 MySQL 行锁上——单行更新吞吐上限约 2000 TPS。这时不能只优化 SQL：
- 把高频写请求先塞进消息队列（如 Kafka/RocketMQ），后台消费者串行或分批落库
- 对计数类场景（如点赞、浏览量），改用 Redis INCR 做原子累加，再按策略（如每 100 次或每 5 秒）批量回写 MySQL
- 必要时做字段级垂直拆分，把频繁更新的字段（如
view_count）单独拎到一张轻量表，减少主表锁竞争
