视图是可复用的查询逻辑封装，用于统一口径、权限控制和简化复杂操作；性能问题源于底层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有什么区别？”怎么答？
直接说清定位差异：