SQL查询缓存的核心作用，是避免对相同查询语句反复执行完整流程（解析、优化、执行、取数据），尤其在读多写少、数据变动不频繁的场景下效果明显。但要注意：MySQL 8.0 已移除查询缓存功能，而其他数据库（如PostgreSQL、SQL Server）或应用层（如Redis、MyBatis二级缓存）仍广泛采用类似机制。关键不在于“有没有缓存”，而在于“如何让缓存真正生效”。
确认查询是否满足缓存条件
不是所有SELECT都能进缓存。必须同时满足：
- 语句以 SELECT 开头，且不含子查询、UNION、存储函数、用户变量等禁止项
- 涉及的表未被修改（INSERT/UPDATE/DELETE/ALTER等操作会清空该表相关缓存）
- 查询中不包含不确定函数，如 NOW()、RAND()、CURDATE()；可用常量替代，例如用 '2024-06-01' 替代 CURDATE()
- 客户端开启了 query_cache_type（MySQL旧版本），且语句未显式加 SQL_NO_CACHE
结构化查询写法，提升缓存命中率
看似相同的逻辑，不同写法会导致缓存键不同，无法复用。建议统一规范：
- 关键字全大写（SELECT / FROM / WHERE），字段名和表名大小写保持一致
- 避免动态拼接空格或换行，比如 "SELECT * FROM user WHERE id = 1" 和 "SELECT * FROM user WHERE id = 1" 是两个缓存项
- 参数尽量用占位符或固定值，不用字符串拼接ID；应用层可做简单规范化，如把 "WHERE status=1" 统一为 "WHERE status = 1"
主动控制缓存生命周期
依赖自动失效容易导致陈旧数据或频繁失效。更可控的方式包括：
- 对实时性要求高的查询，加 SQL_NO_CACHE（MySQL）或使用应用层缓存并设置合理 TTL
- 对配置类、字典类数据（如省市区、订单状态），查完立刻写入 Redis，并在更新时主动 del 对应 key
- 利用数据库通知机制（如 PostgreSQL 的 LISTEN/NOTIFY）或业务层发布更新事件，触发缓存刷新
用应用层缓存补足数据库缓存短板
数据库原生缓存局限大（如全局共享难、粒度粗、开关二元）。推荐组合策略：
- 高频只读小结果集（如用户基本信息）→ 存 Redis，key 设计为 user:123，TTL 30 分钟
- 分页列表类查询 → 缓存“主键ID列表”，再用 IN 查询详情，避免缓存整页大对象
- 用 MyBatis 或 Hibernate 时，开启二级缓存，并为 Mapper 配置 flushInterval 和 readOnly=true 提升安全性和效率
不复杂但容易忽略：缓存的价值不在“存”，而在“准”与“稳”。一次精准的缓存设计，往往比十次慢查询优化更有效。
