sql视图本身不缓存数据，只是封装查询逻辑的虚拟表；真正可缓存的是其查询结果，但需满足可预测、低变更、高复用三条件。适合场景包括固定维度聚合报表、权限隔离后的静态数据集、多租户数据隔离查询及前端轮询看板指标；含now()、依赖会话变量、实时性要求毫秒级或基表高频写入的视图则绝对不应缓存。
SQL 视图本身不缓存数据，它只是封装查询逻辑的“快捷方式”；真正能缓存的是视图背后的查询结果——但必须满足可预测、低变更、高复用三个条件。
哪些业务查询适合用视图+外部缓存组合
视图不是缓存机制，但它能大幅降低缓存接入门槛：把复杂逻辑收进视图定义后，缓存 Key 只需围绕视图名 + 参数生成，不用每次拼接一堆 JOIN 和 WHERE。适合缓存的典型场景有：
- 固定维度聚合报表，比如
daily_sales_by_city视图，每天只刷一次，参数只有日期和城市，Key 可设为view:daily_sales_by_city:20260802:shanghai - 权限隔离后的静态数据集，如
hr_employee_basic视图（只含姓名/部门/工号），全公司员工信息基本不变，TTL 设 1 小时足够 - 多租户共享逻辑但数据隔离的查询，例如 SaaS 系统中按
tenant_id过滤的客户列表视图，每个租户请求带不同tenant_id，缓存 Key 自动区分 - 前端反复轮询的看板指标，如
dashboard_active_users_24h，计算逻辑稳定、更新频率明确（每 15 分钟跑一次 ETL），缓存命中率极高
哪些视图绝对不该缓存结果
缓存错一次，就可能返回脏数据。以下视图背后的结果天然不适合缓存：
- 包含
NOW()、CURRENT_TIMESTAMP或其他运行时函数的视图，每次执行结果都不同，缓存毫无意义 - 依赖用户会话变量（如
@current_user_role）或动态参数（如未绑定的?占位符）的视图，无法生成稳定 Key - 实时性要求毫秒级的查询，比如风控系统中的“最近 1 分钟交易频次”，缓存 TTL 再短也追不上业务节奏
- 底层基表写入极其频繁（如每秒数百次 UPDATE 的订单状态表），缓存刷新成本远高于直接查库
MySQL / PostgreSQL 中视图缓存的实际落地要点
数据库原生不缓存视图结果，你得自己搭链路。关键不在视图怎么写，而在怎么让缓存和视图协同工作：
- PostgreSQL 用户优先考虑
MATERIALIZED VIEW，它真存数据，支持REFRESH CONCURRENTLY，比应用层缓存更稳——但注意它不自动刷新，得配 cron 或 pg_cron - MySQL 没物化视图，得靠定时任务写汇总表，比如
REPLACE INTO summary_daily SELECT ... GROUP BY date, city FROM orders，再让应用查这张表而非视图 - 无论用 Redis 还是 Memcached，Key 必须包含所有影响结果的参数哈希，比如
md5("sales_summary" + date + city + channel)，漏掉一个就可能缓存污染 - 避免在视图里写
SELECT *，字段越多，序列化/反序列化开销越大，缓存体积膨胀，网络传输延迟上升
容易被忽略的缓存穿透与一致性陷阱
视图查不到数据时返回空结果，这个“空”要不要缓存？很多团队踩过坑：
- 没缓存空结果，高频无效请求（比如恶意刷不存在的
user_id）直接打穿 DB，建议对确定不存在的 Key 也缓存 1~2 分钟，加前缀如empty:user:123456 - ETL 刷新汇总表后，没同步清 Redis，导致新数据查不出来——必须在写完汇总表后立刻发消息清 Key，或直接
SET新值，不能依赖被动过期 - 视图定义改了（比如加了个
ROUND()），但应用还用旧 Key 查缓存，结果格式对不上。上线前要批量清掉相关 Key，或把视图版本号写进 Key，如v2:sales_summary:20260802
视图本身轻量，但把它当缓存入口时，真正的复杂点在边界控制：参数是否穷尽、空值是否兜底、刷新与失效是否原子。这些地方一松懈，缓存就从加速器变成故障放大器。
