SQL Server-聚焦使用视图若干限制/建议、视图查询性能问题，你懵逼了？（二十五）

前言

上一节我们简单讲述了表表达式的4种类型，这一系列我们来讲讲使用视图的限制，简短的内容，深入的理解，Always to review the basics。

避免在视图中使用ORDER BY

上一节我们也讲述了使用表表达式必须满足的3个要求，其中就有一个无法保证顺序，也就是说的ORDER BY的问题，我们还是重点看看在视图中的限制。在常规查询中对于排序我们是这样做的。

USE AdventureWorks2012
GO

SELECT *
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderDetailID DESC

接下来我们在视图中对数据进行排序，我们创建视图来看看

USE AdventureWorks2012
GO

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit] GO

CREATE VIEW view_limit
AS
SELECT *
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderDetailID DESC
GO

此时当我们执行创建视图时会发现如下错误

此时在视图内部不能使用ORDER BY我们创建视图后在外部视图使用ORDER BY看看

USE AdventureWorks2012
GO

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit]
GO

CREATE VIEW view_limit
AS
SELECT *
FROM Sales.SalesOrderDetail
GO

SELECT *
FROM view_limit
ORDER BY SalesOrderDetailID DESC

我们再来看看上述在视图内部进行ORDER BY时出现的错误，它说明可以使用TOP、OFFSET等，接下来我们利用TOP来看看实际结果是怎样的。

USE AdventureWorks2012
GO

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit]
GO

CREATE VIEW view_limit
AS
SELECT TOP 100 PERCENT *
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderDetailID DESC
GO

我们再来查询该视图看看返回的结果集

USE AdventureWorks2012
GO

SELECT *
FROM dbo.view_limit

当我们在创建视图时内部使用ORDER BY对结果集进行降序，结果返回的数据压根没有进行降序，同时我们看到查询计划根本没有出现Sort排序操作。我们再来看另外一种情况将返回的数据设置为比100%少一点试试看。

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit]
GO

CREATE VIEW view_limit
AS
SELECT TOP 99.9 PERCENT *
FROM Sales.SalesOrderDetail
ORDER BY SalesOrderDetailID DESC
GO

此时则进行了降序排序，说明在视图中利用TOP、OFFSET就好使了呢？上述查询我们没有做任何条件限制，我们查查表中总共有多少数据和利用视图查询时返回有多少数据看看。

USE AdventureWorks2012
GO

SELECT COUNT(*) AS originalCount
FROM Sales.SalesOrderDetail

SELECT COUNT(*) AS viewCount
FROM dbo.view_limit

虽然在上述情况下我们限制返回的数据最终也按照降序来进行排序，这是相对于小表而言，如果表中数据量比较大的话，此时通过在视图中进行ORDER BY的话将会缺省很多值，所以建议不要在视图中进行ORDER BY而是在视图外部进行ORDER BY。好了这是我们说的第一种限制，我们给出结论。

（1）避免在视图内部使用ORDER BY，当表数据比较小时虽然通过TOP或OFFSET等能解决问题，但是当数据量比较大时此时在视图内部使用ORDER BY会导致更多的数据行缺失，建议在视图外部进行ORDER BY。

避免在视图中使用SELECT *

首先我们通过创建视图来看问题的出现。

USE AdventureWorks2012
GO

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit]
GO

CREATE VIEW view_limit
AS
SELECT *
FROM HumanResources.Shift
GO

接下来我们通过查找原表和视图的方式来看看返回的数据

USE AdventureWorks2012
GO

-- 查找原表
SELECT *
FROM HumanResources.[Shift]
GO
-- 查找视图
SELECT *
FROM view_limit
GO

恩，没毛病，接下来我们在表中添加额外列

USE AdventureWorks2012
GO

ALTER TABLE HumanResources.[Shift]
ADD AdditionalCol INT
GO

我们再来进行上述查询，看看返回的结果集

此时我们发现添加额外列后视图并未显示，当然数据也就不会显示了。此时我们在用视图查询之前进行刷新看看

USE AdventureWorks2012
GO

-- 查找原表
SELECT *
FROM HumanResources.[Shift]
GO

EXEC sp_refreshview ‘view_limit‘

-- 查找视图
SELECT *
FROM view_limit
GO

此时才能返回正确的结果。那么是什么原因导致添加额外列通过视图查询会出现意想不到的结果呢，因为视图在编译方式上对列是枚举的，并且新的表列不会自动添加到视图中，也就是说若我们额外添加了列，此时列根本不会添加到视图中，所以此时我们可以通过sp_refreshview或sp_refreshsqlmodule的方式来刷新视图的元数据。所以我们结论如下

（2）避免在视图中使用SELECT *，当表中添加额外列后会导致视图中不会自动进行添加，虽然我们可以通过sp_refreshview或sp_refreshmodule的方式来刷新视图，但是为了避免混淆，最好是在视图定义中显式列出所需要的列的名称，若添加了额外列，同时在视图中我们需要额外列的话，我们通过ALTER VIEW的方式来修改视图定义即可。

视图查询返回额外列通过JOIN表导致查询性能低效

下面我们直接通过例子进行演示。

IF EXISTS (SELECT * FROM sys.views WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[view_limit]‘))
DROP VIEW [dbo].[view_limit]
GO

CREATE VIEW view_limit
AS
SELECT [SalesOrderID],[SalesOrderDetailID],[CarrierTrackingNumber] ,[OrderQty],sod.[ProductID],[SpecialOfferID],[UnitPrice],[UnitPriceDiscount] ,[LineTotal],[ReferenceOrderID] FROM Sales.SalesOrderDetail sod
INNER JOIN Production.TransactionHistory th ON sod.SalesOrderID = th.ReferenceOrderID
GO

解下来我们进行常规SQL查询和视图查询

USE AdventureWorks2012
GO

SELECT *
FROM dbo.view_limit
WHERE SalesOrderDetailID > 111111
GO

SELECT [SalesOrderID],[SalesOrderDetailID],[CarrierTrackingNumber] ,[OrderQty],sod.[ProductID],[SpecialOfferID],[UnitPrice],[UnitPriceDiscount] ,[LineTotal],[ReferenceOrderID] FROM Sales.SalesOrderDetail sod
INNER JOIN Production.TransactionHistory th ON sod.SalesOrderID = th.ReferenceOrderID
WHERE SalesOrderDetailID > 111111
GO

上述利用常规查询和视图查询开销样，但是现在我们有这样一个场景上述视图是被其他同事所写，但是当我们用时还需要返回额外其他列，所以为了不返回其他多余的数据而和同事撕逼，我们需要再次在视图外部进行JOIN来得到我们额外的列，我们下面来看看。

USE AdventureWorks2012
GO

SELECT v1.*
,th.[Quantity] FROM dbo.view_limit v1
INNER JOIN Production.TransactionHistory th ON v1.SalesOrderID = th.ReferenceOrderID
WHERE SalesOrderDetailID > 111111
GO

SELECT [SalesOrderID],[SalesOrderDetailID],[CarrierTrackingNumber] ,[OrderQty],sod.[ProductID],[SpecialOfferID],[UnitPrice],[UnitPriceDiscount] ,[LineTotal],[ReferenceOrderID] ,th.[Quantity] FROM Sales.SalesOrderDetail sod
INNER JOIN Production.TransactionHistory th ON sod.SalesOrderID = th.ReferenceOrderID
WHERE SalesOrderDetailID > 111111
GO

此时额外返回了Quantity列对视图再次进行JOIN，我们看看查询计划开销

此时发现利用视图查询开销更多，而常规查询不过是多添加一个列而已没有任何改变。我们继续往下看

默认情况下在视图上创建索引无效

我们在前面一直讨论过关于索引的建立的问题，而且索引都是建立在表上，那么我们将索引建立在视图上情况是怎样的呢，是不是查询效率会得到提升呢？我们首先创建测试表并插入数据

USE AdventureWorks2012
GO

IF EXISTS (SELECT * FROM sys.objects
WHERE OBJECT_ID = OBJECT_ID(N‘[dbo].[ViewTable]‘) AND TYPE IN (N‘U‘))
DROP TABLE [dbo].[ViewTable]
GO

CREATE TABLE ViewTable (ID1 INT, ID2 INT, SomeData VARCHAR(100))
INSERT INTO ViewTable (ID1,ID2,SomeData)
SELECT TOP 100000 ROW_NUMBER() OVER (ORDER BY o1.name),
ROW_NUMBER() OVER (ORDER BY o2.name),
o2.name
FROM sys.all_objects o1
CROSS JOIN sys.all_objects o2
GO

上述我们创建了测试的视图表ViewTable并插入了10万条测试数据，接下来我们对表建立索引。

USE AdventureWorks2012
GO

CREATE UNIQUE CLUSTERED INDEX [idx_original_table] ON dbo.ViewTable
(
ID1 ASC
)

接下来我们来创建视图并在视图上创建索引

USE AdventureWorks2012
GO

CREATE VIEW ViewLimit
WITH SCHEMABINDING
AS
SELECT ID1,ID2,SomeData
FROM dbo.ViewTable
GO

CREATE UNIQUE CLUSTERED INDEX [idx_view_table] ON [dbo].[ViewLimit]
(
ID2 ASC
)
GO

上述我们需要注意，当在视图上创建索引时必须指定WITH SCHAMABINDING，否则不允许在视图上创建索引。我们最后通过常规查询和视图查询来看看查询计划情况

USE AdventureWorks2012
GO

SELECT ID1,ID2,SomeData
FROM dbo.ViewTable
GO

SELECT ID1,ID2,SomeData
FROM dbo.ViewLimit
GO

此时我们发现视图查询利用的索引不是我们创建的索引idx_view_table，主要原因是因为视图和表是关联的，所以查询计划决定在表上的索引比在视图上创建的索引更加高效。 当我们在WITH中强制指定noexpand此时将会执行在视图上创建的索引，因为此时视图已经和原始表没有关系，它是独立的，如下：

USE AdventureWorks2012
GO

SELECT ID1,ID2,SomeData
FROM dbo.ViewTable
GO

SELECT ID1,ID2,SomeData
FROM dbo.ViewLimit
WITH(NOEXPAND)
GO

在视图上创建索引这个问题比较复杂，我们就不讨论了，一般通过常规查询都能解决的问题何必劳驾视图呢。这个我们需要注意一下就行。

总结

本节我们讲了几个使用视图时的限制以及建议等问题，下节我们还是会讨论使用视图的其他限制，简短的内容，深入的理解，我们下节再会。

时间： 2024-10-14 06:29:04

SQL Server-聚焦使用视图若干限制/建议、视图查询性能问题，你懵逼了？（二十五）的相关文章

SQL Server中多表连接时驱动顺序对性能的影响

原文:SQL Server中多表连接时驱动顺序对性能的影响 本文出处:http://www.cnblogs.com/wy123/p/7106861.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他) 最近在SQL Server中多次遇到开发人员提交过来的有性能问题的SQL,其表面的原因是表之间去的驱动顺序造成的性能问题,具体表现在(已排除其他因素影响的情况下),存储过程偶发性的执行时间超出预期,甚至在调试的时候

SQL Server调优系列基础篇（子查询运算总结）

原文:SQL Server调优系列基础篇(子查询运算总结) 前言 前面我们的几篇文章介绍了一系列关于运算符的介绍,以及各个运算符的优化方式和技巧.其中涵盖:查看执行计划的方式.几种数据集常用的连接方式.联合运算符方式.并行运算符等一系列的我们常见的运算符.有兴趣的童鞋可以点击查看. 本篇我们介绍关于子查询语句的一系列内容,子查询一般是我们形成复杂查询的一些基础性操作,所以关于子查询的应用方式就非常重要. 废话少说,开始本篇的正题. 技术准备 数据库版本为SQL Server2008R2,利用微软

【能力提升】SQL Server常见问题介绍及高速解决建议

前言 本文旨在帮助SQL Server数据库的使用人员了解常见的问题.及高速解决这些问题.这些问题是数据库的常规管理问题,对于非常多对数据库没有深入了解的朋友提供一个大概的常见问题框架. 以下一些问题是在近千家数据库用户诊断时发现的常规问题.本文分为[常见问题诊断流程]-[常见问题]-[常见问题高速解决的建议] 常见问题诊断流程 概览模块-[汇总]了解系统 了解系统性能(语句运行时间.会话等待) 语句运行时间:横坐标为时间范围,纵坐标为在运行时间在范围内分布的语句数量. (本例:收集时间内语句运

SQL Server常见问题介绍及快速解决建议

前言 本文旨在帮助SQL Server数据库的使用人员了解常见的问题,及快速解决这些问题.这些问题是数据库的常规管理问题,对于很多对数据库没有深入了解的朋友提供一个大概的常见问题框架. 下面一些问题是在近千家数据库用户诊断时发现的常规问题,本文分为[常见问题诊断流程]-[常见问题]-[常见问题快速解决的建议] 常见问题诊断流程 概览模块-[汇总]了解系统 了解系统性能(语句执行时间.会话等待) 语句执行时间:横坐标为时间范围,纵坐标为在执行时间在范围内分布的语句数量. (本例:收集时间内语句执行

sql server中的开窗函数over、视图、事物

一.开窗函数over的作用有两个: 1.排序order by,row_number,翻页 2.划区partition by,结合聚合函数针对某部分数据进行汇总 翻页的sql server 语句: select * from ( select *,row_number() over( order by id) as num from 表名) as t where t.num>6 and t.num<10 二.视图:用于存储一个select语句.并不是存储数据的一个容器. create view

强制SQL Server执行计划使用并行提升在复杂查询语句下的性能

最近在给一个客户做调优的时候发现一个很有意思的现象,对于一个复杂查询(涉及12个表)建立必要的索引后,语句使用的IO急剧下降,但执行时间不降反升,由原来的8秒升到20秒. 通过观察执行计划,发现之前的执行计划在很多大表连接的部分使用了Hash Join,由于涉及的表中数据众多,因此查询优化器选择使用并行执行,速度较快.而我们优化完的执行计划由于索引的存在,且表内数据非常大,过滤条件的值在一个很宽的统计信息步长范围内,导致估计行数出现较大偏差(过滤条件实际为15000行,步长内估计的平均行数为80

在 SQL Server 数据库的 WHERE 语句中使用子查询

这是关于子查询语句的一系列文章中的第三篇.在这篇文章中我们将讨论WHERE语句中的子查询语句.其他的文章讨论了其他语句中的子查询语句. 本次课程中的所有例子都是基于Microsoft SQL Server Management Studio和AdventureWorks2012数据库的.读者可以阅读我的SQL Server使用入门学习使用这些免费的工具. 在WHERE语句中使用子查询 在WHERE语句中使用子查询是非常常见的.常见的用法是用EXISTS或IN测试存在性.在某些情况下重新考虑查询语

SQL Server的优化器会缓存标量子查询结果集吗

在这篇博客"ORACLE当中自定义函数性优化浅析"中,我们介绍了通过标量子查询缓存来优化函数性能: 标量子查询缓存(scalar subquery caching)会通过缓存结果减少SQL对函数(Function)的调用次数, ORACLE会在内存中构建一个哈希表来缓存标量子查询的结果. 那么SQL Server的优化器是否也会有类似这样的功能呢? 抱着这样的疑问,动手测试了一下,准备测试环境 CREATE TABLE TEST (    ID  INT );     DECLARE

sql server 删除表及表的相关视图、存储过程、方法

注意:进行此操作前需先备份数据库,免得删错无法恢复 1.查询 SELECT Name ,type FROM SysObjects WHERE name LIKE '%cases%' 2.拼接语句 SELECT 'drop Procedure '+ Name FROM SysObjects WHERE name LIKE '%cases%' AND type='p'; SELECT 'drop view '+ Name FROM SysObjects WHERE name LIKE '%cases