视图是可复用的查询逻辑封装，用于统一口径、权限控制和简化复杂操作；性能问题源于底层 SELECT 反复执行、嵌套展开、条件无法下推及聚合索引缺失。
SQL 视图不是真实表，而是保存的 SELECT 查询语句，用起来像表，但不存数据。面试常考它“怎么用”和“为什么慢”，核心就两点：逻辑封装能力 + 查询执行开销。
视图到底解决什么问题？
视图本质是 可复用的查询逻辑封装，不是为了省写 SQL，而是为了统一口径、控制权限、简化复杂操作：
- 多部门共用同一张销售统计逻辑（比如“近 30 天各区域净销售额 = 实收 - 退款 - 折扣”），用视图定义一次，所有人查
v_sales_summary，避免各自写错公式 - 给客服人员只开放
v_customer_basic视图，隐藏身份证号、银行卡等敏感字段，比在应用层拼 SQL 更安全可靠 - 把多表 JOIN+ 聚合 + 过滤（如订单 + 商品 + 用户 + 地址）封装进视图，前端调用时只需
SELECT * FROM v_order_detail，不用每次理解 10 行 JOIN
视图性能为什么可能变差？
视图本身不慢，慢的是它背后那条 SELECT 被反复执行，尤其嵌套或未加索引时：
- “视图套视图”会层层展开 ：定义
v_top_user基于v_user_behavior，而后者又基于v_raw_log，最终执行时可能变成三层子查询，优化器难以准确估算行数 - WHERE 条件无法下推到基表 ：如果视图里写了
WHERE status = 'active'，但外部再加AND city = 'shanghai'，某些数据库（如旧版 MySQL）不会自动把city条件推进到原始表，导致先扫全量再过滤 - 聚合视图不能走索引扫描：像
CREATE VIEW v_monthly_sales AS SELECT month, SUM(amount) FROM orders GROUP BY month，查某个月仍要全表 GROUP BY，除非基表对 month 建了合适索引
怎么写出高性能视图？
关键不是“少用视图”，而是让视图行为可预期、可干预：
- 单层视图优先，避免
CREATE VIEW v2 AS SELECT * FROM v1这种链式引用 - 视图定义中尽量不写固定 WHERE（如
WHERE deleted = 0），改由调用方传参过滤；若必须写，确保对应字段在基表上有索引 - 在 PostgreSQL 或 SQL Server 中，可用
MATERIALIZED VIEW（物化视图）缓存结果，适合变化不频繁的统计类场景 - MySQL 8.0+ 支持
WITH CHECK OPTION，可在 INSERT/UPDATE 时校验数据是否满足视图条件，兼顾安全与可控
面试被问“视图和 CTE 有什么区别？”怎么答？
直接说清定位差异：
- 视图是数据库对象，创建后持久存在，可授权、可被多个 SQL 复用、可嵌套引用
- CTE（WITH 子句）是语法结构，只在当前 SQL 内有效，不保存，主要用于提升可读性或实现递归查询（如组织架构树）
- 性能上无绝对优劣：简单 CTE 可能被内联展开，和视图等价；但复杂 CTE 若被多次引用（如
WITH t AS (……) SELECT * FROM t UNION ALL SELECT * FROM t），某些数据库会重复执行，而视图至少逻辑复用
