SQL Server视图的成本与本质：存储、更新机制问询

咱们先从最常见的普通视图说起（这也是你默认会创建的类型，除非特意指定特殊类型）：

1. 普通视图会存储数据副本，占用额外内存/存储空间吗？ #

不会。普通视图本质上就是一个保存起来的SELECT语句，它本身不存储任何实际数据，也不会占用额外的内存或磁盘空间来存放数据副本——所有数据都依然保存在源表中。

2. 源表变化时，视图的数据怎么更新？ #

其实根本不存在“视图数据更新”这回事——因为视图本身没有数据。当你查询视图的时候，数据库引擎会自动把视图的定义（也就是那个保存的SELECT语句）展开，和你的查询条件合并，然后直接去查询最新的源表数据。所以源表的数据变了，你查视图得到的结果自然就是最新的，不需要手动或自动去“更新视图”。

3. 查询视图会有额外的计算时间成本吗？ #

查询普通视图的额外开销几乎可以忽略不计。数据库引擎在处理视图查询时，会做一个“视图展开”的操作，把视图的SELECT语句和你的查询逻辑合并成一个完整的执行计划，这个过程的开销非常小。最终的查询性能，和你直接把视图里的SELECT语句写在查询里几乎完全一样。

当然，如果视图的定义本身很复杂（比如包含多层嵌套、大量连接或聚合），那查询视图的成本和直接执行那个复杂SELECT是一样的——但这不是视图的锅，是SQL逻辑本身的复杂度导致的。

不过这里要提一下索引视图（SQL Server中的叫法，其他数据库可能叫物化视图）：这种视图会把查询结果物化（也就是实际存储起来），占用额外的存储空间。当源表数据变化时，数据库引擎会自动同步更新这个物化的数据，这时候会产生额外的写入成本（因为要维护视图的索引和存储的数据），但好处是查询索引视图的时候速度会更快，因为直接读物化好的数据，不需要重新计算。

4. 普通视图是不是“一种保存SELECT语句的方式”？ #

可以这么说，但它的作用不止于此：

• 简化复杂查询：把常用的复杂SELECT封装成视图，后续查询直接用视图名，不用重复写长SQL；
• 封装逻辑：如果业务逻辑变化，只需要修改视图的定义，所有用到这个视图的查询都会自动生效；
• 权限控制：可以给用户授予视图的访问权限，但不授予源表的权限，让用户只能看到视图里暴露的列/数据，保证数据安全。

内容的提问来源于stack exchange，提问作者Pierre Nicolas