Question

使用SqlServer Views有什么缺点？

我经常创建视图以非规范化形式显示我的数据。

我发现查询其中一个连接而不是生成许多表之间具有复杂连接的复杂查询更容易，因此更快，更不容易出错，并且更多自我记录。特别是当我从不同的角度分析相同的数据（许多相同的字段，相同的表连接）时。

但创建和使用这些视图是否有成本？

我是否放慢速度（或加速？）查询处理？

Answer 1

来到Views时有优点和缺点。

优点：

它们是虚拟表，不作为唯一对象存储在数据库中。所有存储的都是SELECT语句。
可以通过限制用户可以看到的内容来将其用作安全措施。
通过将它们封装到视图中，可以使常用的复杂查询更易于阅读。这是一把双刃剑 - 见缺点＃3。

缺点：

它没有缓存优化的执行计划，因此它不会像存储过程那么快。
因为它基本上只是SELECT的抽象，所以它比做一个纯SELECT慢得多。
它可以隐藏复杂性并导致陷阱。（Gotcha：ORDER BY不予尊重）。

我个人的意见是不使用视图，而是使用存储过程，因为它们提供了视图的安全性和封装，但也提高了性能。

Answer 2

使用视图的一个可能的缺点是，您抽象了底层设计的复杂性，这可能导致初级开发人员和报表创建者滥用。

对于一个特别大而复杂的项目，我设计了一组视图，这些视图主要由报表设计者用来填充水晶报表。几周后我发现初级开发人员已经开始使用这些视图来获取聚合并加入这些已经很大的视图，因为它们在那里并且易于使用。（数据库中有一个强大的EAV设计元素。）在初级开发人员开始询问为什么看似简单的报告需要花费很多时间才能执行之后，我发现了这一点。

Answer 3

视图的效率在很大程度上取决于底层表。视图实际上只是一种有组织的查看查询结果的一致方式。如果用于构成视图的查询是好的，并且在基础表上使用适当的索引，则视图不应对性能产生负面影响。

在SQL Server中，您还可以create materialized or indexed views（自SQL Server 2000起），这会稍微提高速度。

Answer 4

我也经常使用观点。然而，需要注意的一点是，如果基础表经常更改（特别是在开发期间），使用大量视图可能很难维护。

编辑：话虽如此，我发现能够简化和重复使用复杂查询的便利性和优势超过了维护问题，尤其是在负责任地使用视图的情况下。

Answer 5

当视图包含最终查询未最终使用的逻辑，列，行或表时，视图可能会对性能造成损害。我不能告诉你我见过多少次：

SELECT ... 
FROM (View with complex UNION of ActiveCustomer and InactiveCustomer tables)
WHERE Active = True

（从而过滤掉InactiveCustomer表中视图中包含的所有行）或

SELECT (one column)
FROM (view that returns 50 columns)

（SQL必须检索大量数据，然后在以后的步骤中将其丢弃。可能这些其他列的检索成本很高，例如通过书签查找）或

SELECT ...
FROM (view with complex filters)
WHERE (entirely different filters)

（如果直接查询表，SQL可能使用了更合适的索引），或

SELECT (only fields from a single table)
FROM (view that contains crazy complex joins)

（通过连接的大量CPU开销，以及后来丢弃的表读取的不必要的IO），或者我最喜欢的：

SELECT ...
FROM (Crazy UNION of 12 tables each containing a month of data)
WHERE OrderDate = @OrderDate

（读取12个表时，只需要读取1）。

在大多数案例中，SQL非常聪明，可以“透视封面”并提出有效的查询计划。但在其他情况下（特别是非常复杂的情况），它不能。在上述每种情况中，答案都是删除视图并查询基础表。

至少（即使您认为SQL无论如何都足够智能化），消除视图有时可以使您自己的查询调试和优化更容易（更明显需要什么）要做的事。）

Answer 6

我遇到的观点的缺点是，在将它们合并到分布式查询中时，性能会下降。这篇SQLMag文章讨论了 - 当我在演示中使用高度人工数据时，我在“现实世界”中一次又一次地遇到这个问题。

尊重您的观点，他们会很好地对待您。

Answer 7

SQL Server中视图的各种限制是什么？

观点的前11个限制

视图不支持COUNT（）;但是，它可以支持COUNT_BIG（）
ORDER BY子句在View
当我们需要另一列时，常规查询或存储过程为我们提供了灵活性;我们可以立即为常规查询添加一列。如果我们想对Views做同样的事情，那么我们必须先修改它们
在视图上创建的索引不经常使用
创建视图后，如果基本表中添加或删除了任何列，则在刷新之前通常不会将其反映在视图中
索引视图中不允许使用UNION操作
我们无法在嵌套视图上创建索引情况意味着我们无法在从另一个视图构建的视图上创建索引。
索引视图中不允许自选加入
索引视图中不允许外部加入
索引视图中不允许跨数据库查询

来源 SQL MVP Pinal Dave

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/

Answer 8

当我开始时，我总是看到视图增加了性能开销，但是经验描绘了一个不同的故事（视图机制本身具有可忽略的开销）。

这完全取决于底层查询是什么。查看索引视图here或here，最终您应该通过两种方式测试性能以获得清晰的效果配置文件

Answer 9

我最大的'抱怨'是ORDER BY在视图中不起作用。虽然这是有道理的，但如果没有预期的话，它就会跳起来咬人。因此我不得不将远离从使用视图切换到SPROCS（它们有足够多的问题），在一些情况下我无法在以后指定ORDER BY。（我希望有一个带有“最终视图”的构造 - 例如可能包含 - 语义顺序）。

http://blog.sqlauthority.com/2010/10/03/sql-server-the-limitations-of-the-views-eleven-and-more/（限制＃1是关于ORDER BY： - ）

Answer 10

以下是允许在视图中引用order by的SQL hack：

create view toto1 as 
select top 99.9999 percent F1
from Db1.dbo.T1 as a 
order by 1

但我的偏好是使用Row_Number：

create view toto2 as 
select *,  ROW_NUMBER() over (order by [F1]) as RowN from ( 
select f1
from Db1.dbo.T1) as a

使用SqlServer Views有什么缺点？

10 个答案: