视图比普通表慢是因为每次查询都需实时解析并执行其定义sql，产生额外开销，尤其嵌套或关联大表时执行计划更差；无索引、优化受限（如where下推失败）、不支持参数，仅适合权限控制与逻辑封装，不可作缓存。
视图 SELECT 为什么比普通表慢？
因为视图本身不存数据，每次查 SELECT * FROM my_view 都会实时展开定义里的 SQL，再执行——相当于多了一层解析+重写开销，尤其嵌套视图或关联多张大表时，执行计划可能更差。
常见错误现象：EXPLAIN 显示扫描行数远超预期、pg_stat_statements 中视图查询的 total_time 明显偏高。
- 使用场景：适合权限控制、逻辑封装、简化复杂查询入口，但别把它当缓存用
- 参数差异：PostgreSQL 视图不支持传参；MySQL 8.0+ 的内联表值函数（
WITH+LATERAL）可部分替代 - 性能影响：无索引可言，底层表加了索引也不直接作用于视图字段；若视图里含
ORDER BY或LIMIT，还可能阻止上层查询的优化（如外层WHERE下推失败）
物化视图更新不及时，REFRESH 卡住怎么办？
物化视图本质是“快照”，REFRESH 就是重跑定义 SQL 再全量覆盖数据。卡住通常是因为锁表（PostgreSQL 默认 CONCURRENTLY 模式才不阻塞读）、或源表太大、或事务里混了 DML。
常见错误现象：REFRESH MATERIALIZED VIEW mv_orders 执行几小时没返回；pg_locks 查到 AccessExclusiveLock 持有者长时间未释放。
- 使用场景：适合报表底表、BI 查询频次高但容忍分钟级延迟的数据
- 参数差异：PostgreSQL 要加
CONCURRENTLY才允许并发读；Oracle 的物化视图支持快速刷新（FAST REFRESH），依赖日志和主键，但维护成本高 - 兼容性影响：MySQL 原生不支持物化视图（需用定时任务+普通表模拟）；SQLite 完全没有
普通表加索引 vs 物化视图预计算，哪个更快？
不是非此即彼。普通表加对索引，能加速带过滤条件的点查或范围查；物化视图适合固定聚合逻辑（比如每天销售额汇总），把计算提前做掉。
常见错误现象：给宽表建了十几个单列索引，INSERT 变慢三倍，但 SELECT 并没快多少；或者建了物化视图却很少查它，反而拖慢 ETL 流程。
- 性能权衡：索引提升查询但拖慢写入；物化视图减少重复计算但占用额外存储、且刷新有延迟
- 使用条件：如果查询条件高度动态（比如用户自定义时间范围+多维筛选），索引更灵活；如果 80% 查询都走同一聚合口径，物化视图收益明确
- 示例：统计每类商品月销量，用物化视图
mv_monthly_sales_by_category比每次GROUP BY category, date_trunc('month', order_time)快得多，尤其订单表过亿行时
视图里用 UNION ALL 或子查询，性能会崩吗？
会，而且非常容易被忽略。视图定义里一旦出现非内联可优化结构（比如顶层 UNION ALL、相关子查询、窗口函数未加过滤），PostgreSQL 和 MySQL 都可能放弃下推优化，导致全表扫描后再合并。
常见错误现象：视图查得慢，但把视图定义 SQL 拿出来单独跑却很快；EXPLAIN ANALYZE 显示实际扫描行数是单表的 N 倍。
- 根本原因：优化器无法保证下推
WHERE条件后各分支结果仍满足语义（比如UNION ALL各边字段类型隐式转换不同） - 实操建议：优先用
WITH替代嵌套子查询；避免在视图顶层用UNION ALL，改用应用层合并或分区表 - 小技巧：PostgreSQL 12+ 支持
MATERIALIZED关键字修饰 CTE，可强制物化中间结果，但仅限单次查询有效，不解决视图问题
真正难的从来不是选哪个，而是搞清查询模式是否稳定、写入频率能否容忍延迟、以及 DBA 是否愿意为物化视图配监控告警——这些细节一漏，再好的设计也会在上线后变成慢查询源头。
