读多写少场景下，应通过分层缓存（Redis集群+TTL、Caffeine+主动失效、冷数据直查）、防穿透/雪崩措施、精准联合索引、读写分离与查询降级来提升查询性能并控制写入开销。
读多写少的业务场景下，核心目标是让查询飞起来，同时控制写入开销不飙升。关键不在堆硬件，而在缓存与索引的协同设计——缓存扛住高频读，索引精准响应非缓存路径，两者边界清晰、互不干扰。
缓存分层：按热度和一致性要求选策略
不是所有数据都适合放同一层缓存。高频、低更新、容忍短时过期的数据（如商品类目、用户等级规则）走 Redis 集群+TTL；中频、需强一致的（如用户当前订单状态）用本地缓存（Caffeine）+主动失效；低频或冷数据（如历史订单详情）直接查库，不缓存。
- 避免缓存穿透：对空结果也缓存（短 TTL，如 2 分钟），配合布隆过滤器拦截非法 ID 查询
- 避免缓存雪崩：不同 key 的 TTL 加随机偏移（如 base=30min + rand(0–300)秒）
- 写操作后优先删缓存，而非更新缓存——防止并发写导致脏数据；删除失败要进消息队列重试
索引精简：只建真正被 WHERE / ORDER BY / JOIN 用到的字段
读多场景容易陷入“全字段加索引”误区。真实慢查往往集中在少数几个查询模式上。先用慢日志 + EXPLAIN 分析 TOP 10 查询，再针对性建索引。例如：
- 用户中心页查
SELECT * FROM orders WHERE user_id = ? AND status IN ('paid','shipped') ORDER BY created_at DESC LIMIT 20→ 建联合索引(user_id, status, created_at) - 搜索页支持模糊前缀匹配
WHERE title LIKE '手机%'→ 可用前缀索引title(20)，但注意长度覆盖绝大多数实际前缀 - 避免在低选择性字段（如 gender、is_deleted）单独建索引；必要时用表达式索引或部分索引（PostgreSQL）
读写分离与查询降级：把压力从主库摘出来
主库只承担写入和强一致读；所有列表页、详情页、统计看板等非实时场景，全部路由到只读从库。从库延迟需监控（如 MySQL 的 Seconds_Behind_Master
- 应用层用 ShardingSphere 或 MyCat 实现透明读写分离，避免业务代码感知
- 对“最新 N 条”类查询（如最新评论），可接受秒级延迟，强制走从库；对“我刚下的单在哪”，走主库或缓存
- 聚合类查询（如销量统计）提前物化到宽表或离线计算结果表，避免运行时 JOIN 大表
冷热分离：让热数据更轻，冷数据更省
时间维度明显的数据（如订单、日志、行为记录）做按月/按天分表，并将 3 个月前的历史数据归档到低成本存储（如 OSS + Presto 或 ClickHouse）。主业务库只保留热数据，索引体积小、缓存命中率高、备份恢复快。
- 归档后保留归档标记（如
archived_at字段），业务查询带条件时自动跳过归档分区 - 使用 MySQL 的 PARTITION BY RANGE 或 TiDB 的 Region 分裂机制，物理隔离热冷数据
- 冷数据查询入口统一收口，走异步导出或专用 API，不走主业务链路
不复杂但容易忽略：缓存与索引不是越多越好，而是越准越好。每次加缓存前问一句“这个 key 真的会被反复读吗”，每次建索引前跑一遍 EXPLAIN——真正的性能优化，藏在对业务查询模式的诚实理解里。
