SQL Server-聚焦计算列或计算列持久化查询性能（二十二）

前言

上一节我们详细讲解了计算列以及计算列持久化的问题，本节我们依然如前面讲解来看看二者查询性能问题，简短的内容，深入的理解，Always to review the basics。

持久化计算列比非持久化计算列性能要好

我们开始创建两个一样的表并都插入100条数据来进行比较，对于计算列我们重新进行创建计算列和非计算列持久化。

CREATE TABLE [dbo].[ComputeColumnCompare] (ID INT,
FirstName VARCHAR(100),
LastName CHAR(8000))
GO
INSERT INTO [dbo].[ComputeColumnCompare] (ID,FirstName,LastName)
SELECT TOP 100  ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob‘,
CASE WHEN ROW_NUMBER() OVER (ORDER BY a.name)%2 = 1 THEN ‘Smith‘
ELSE ‘Brown‘ END
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO

在ComputeColumn表上创建计算列

USE TSQL2012
GO

ALTER TABLE dbo.ComputeColumn ADD
FullName AS POWER(LEN(LEFT((FirstName+CAST(ID AS VARCHAR(100))),3)), 12)
GO

在ComputeColumnCompare表上创建计算持久化列

USE TSQL2012
GO

ALTER TABLE dbo.ComputeColumnCompare ADD
FullName_P AS POWER(LEN(LEFT((FirstName+CAST(ID AS VARCHAR(100))),3)), 12) PERSISTED
GO

此时我们来运行两个表对计算列和计算列持久化列的查询

USE TSQL2012
GO

SELECT FullName
FROM dbo.ComputeColumn
WHERE FullName = 531441
GO
SELECT FullName_P
FROM dbo.ComputeColumnCompare
WHERE FullName_P = 531441
GO

此时二者的开销是一样的，只是非持久化列多了一个Compute Scalar操作，主要是因为它计算值是在运行时，此时我们来看看操作陈本。

我们看到二者性能还是有一点差异，所以我们能够知道如果计算操作比较复杂时利用持久化来提前进行计算性能会比非持久化列更好。是不是所有情况下持久化列性能都比持久化列性能要好呢？继续往下看。

非持久化计算列比持久化计算列性能要好

我们再来创建测试表并插入1万条数据来进行比较。

USE TSQL2012
GO

CREATE TABLE [dbo].[ComputeColumn] (ID INT,
FirstName VARCHAR(100),
LastName CHAR(800))
GO
CREATE TABLE [dbo].[ComputeColumnCompare](ID INT,
FirstName VARCHAR(100),
LastName CHAR(800))
GO
USE TSQL2012
GO

INSERT INTO  [dbo].[ComputeColumn](ID,FirstName,LastName)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob‘,
CASE WHEN ROW_NUMBER() OVER (ORDER BY a.name)%2 = 1 THEN ‘Smith‘
ELSE ‘Brown‘ END
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO
INSERT INTO [dbo].[ComputeColumnCompare](ID,FirstName,LastName)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob‘,
CASE WHEN ROW_NUMBER() OVER (ORDER BY a.name)%2 = 1 THEN ‘Smith‘
ELSE ‘Brown‘ END
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO

接下来在两表上创建持久化计算列和非持久化计算列

USE TSQL2012
GO

ALTER TABLE dbo.ComputeColumn ADD
FullName AS (FirstName+‘ ‘+LastName)
GO

ALTER TABLE dbo.ComputeColumnCompare ADD
FullName_P AS (FirstName+‘ ‘+LastName) PERSISTED
GO

最后我们进行查询看看查询计划结果

USE TSQL2012
GO

SELECT FullName
FROM dbo.ComputeColumn
WHERE FullName = ‘Bob Smith‘
GO
SELECT FullName_P
FROM dbo.ComputeColumnCompare
WHERE FullName_P = ‘Bob Smith‘
GO

到这里我们发现非持久化计算列性能要比持久化计算列性能要好，和上面对照的话我已经明确进行了标记定义列的大小以及插入行的多少是不同的，所以对于持久化列和非持久化列二者并没有绝对性能的谁好谁好，当我们想要看二者谁性能更佳时，我们可能需要考虑定义列的大小、数据行的多少等等。下面我们还看最后一种情况，就是在计算列上来创建索引。

非持久化计算列提高查询性能

我们继续创建测试表

USE TSQL2012
GO

CREATE TABLE [dbo].[ComputeColumn] (ID INT,
FirstName VARCHAR(100),
LastName VARCHAR(100))
GO
CREATE TABLE [ComputeColumnCompare] (ID INT,
FirstName VARCHAR(100),
LastName VARCHAR(100))
GO
USE TSQL2012
GO

INSERT INTO [dbo].[ComputeColumn] (ID,FirstName,LastName)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob‘,
CASE WHEN ROW_NUMBER() OVER (ORDER BY a.name)%2 = 1 THEN ‘Smith‘
ELSE ‘Brown‘ END
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO
INSERT INTO  [dbo].[ComputeColumnCompare](ID,FirstName,LastName)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY a.name) RowID,
‘Bob‘,
CASE WHEN ROW_NUMBER() OVER (ORDER BY a.name)%2 = 1 THEN ‘Smith‘
ELSE ‘Brown‘ END
FROM sys.all_objects a
CROSS JOIN sys.all_objects b
GO

在ComputeColumn表上创建计算列并创建一个非聚集索引

ALTER TABLE dbo.ComputeColumn ADD
FullName AS (FirstName+‘ ‘+LastName)
GO

CREATE NONCLUSTERED INDEX IX_CompCol_CityTrim
ON dbo.ComputeColumn (FullName)
GO

在ComputeColumnCompare表上创建计算列

ALTER TABLE dbo.ComputeColumnCompare ADD
FullName_P AS (FirstName+‘ ‘+LastName)
GO

最后查询两个表看看查询计划结果

USE TSQL2012
GO

SELECT FullName
FROM dbo.ComputeColumn
WHERE FullName = ‘Bob Smith‘
GO
SELECT FullName_P
FROM dbo.ComputeColumnCompare
WHERE FullName_P = ‘Bob Smith‘
GO

从上述我们知道对计算列创建一个索引能很好的提高查询性能，当然了上述仅仅只是返回计算列，若返回其他列的话可能会导致Key Lookup，但是从另外一个角度来讲还是能提高查询性能，为了解决Key Lookup问题建立太多索引也是有问题的，具体情况具体分析吧。这里并没有比较持久化计算列和非持久化计算列的性能，二者其实是一样的，就没有比较了，只是在利用持久化在数据存储上不同而已。参考资料：【http://blog.sqlauthority.com/2010/08/03/sql-server-computed-column-persisted-and-performance/】

总结

到此我们算是结束了对于计算列以及关于计算列持久的概念和性能的分析，下节我们再看看其他查询的知识，接着就进入表表达式的学习，简短的内容，深入的理解，我们下节再会。

时间： 2024-12-13 17:07:25

SQL Server-聚焦计算列或计算列持久化查询性能（二十二）的相关文章

第16/24周 SQL Server 2014中的基数计算

大家好,欢迎回到性能调优培训.上个星期我们讨论在SQL Server里基数计算过程里的一些问题.今天我们继续详细谈下,SQL Server 2014里引入的新基数计算. 新基数计算 SQL Server 2014里一个增强是新的基数计算.上个星期你已经学到老基数计算有些限制,会生成错误的估计,这会导致不好的执行计划表现.截至SQL Server 2012,你一直在使用自SQL Server 7.0引入的基数计算. 当然,几年来也有很多问题被修正,但默认它们都没启用的——你需要启用SQL Serv

在SQL Server 2014里可更新的列存储索引 （Updateable Column Store Indexes）

传统的关系数据库服务引擎往往并不是对超大量数据进行分析计算的最佳平台,为此,SQL Server中开发了分析服务引擎去对大笔数据进行分析计算.当然,对于数据的存放平台SQL Server数据库引擎而言,也是需要强大的数据处理能力的. 在SQL Server 2012时,SQL Server 引入了列存储索引,用以显著提供高传统数据仓库类型语句的性能,并在SQL Server 2014中做了进一步加强.本文将在对SQL Server 2012列存储索引简单介绍的基础上,进一步解释SQL Serve

sql server存储过程分页，行变列

CREATE PROCEDURE [dbo].[PROC_GetPriviousAndNextDetailContent]@Index varchar(20),--表主键@Table varchar(100),--从哪个表获取数据@Columns varchar(100),--需要获取哪些字段@OrderStr varchar(100),--排序字段及方式@Where1    varchar(100),--row_number中的初步过滤条件@Where2 varchar(100)--当前要查询

SQL Server 强行Insert包含自增列值的记录

SET IDENTITY_INSERT 表 ON INSERT INTO 表 ([ID] ,[SequenceNumber] ,[EnumCode] ,[Description]) VALUES (6 ,1 ,'Empty' ,'Empty') SET IDENTITY_INSERT 表 OFF 此处ID为自增列 SQL Server 强行Insert包含自增列值的记录,布布扣,bubuko.com

向SQL Server 现有表中添加新列并添加描述.

注: sql server 2005 及以上支持. 版本估计是不支持(工作环境2005,2008). 工作需要, 需要向SQL Server 现有表中添加新列并添加描述. 从而有个如下存储过程. (先附上存储过程然后解释) 代码 /********调用方法********** 作用: 添加列并添加列描述信息 调用: exec [SetColumnInfo] '表名', '列名', N'列说明,描述','列类型{默认:NVARCHAR(50)}','列默认值{默认:NULL}' *********

SQL Server 2008 R2——PIVOT 行转列 以及聚合函数的选择

原文:SQL Server 2008 R2--PIVOT 行转列 以及聚合函数的选择 ==================================声明================================== 本文原创,转载在正文中显要的注明作者和出处,并保证文章的完整性. 未经作者同意请勿修改(包括本声明),保留法律追究的权利. 未经作者同意请勿用于学术性引用. 未经作者同意请勿用于商业出版.商业印刷.商业引用. 本文不定期修正完善,为保证内容正确,建议移步原文处阅读. 本文

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

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

爪哇国新游记之二十二----算术表达式计算求值

代码: import java.util.ArrayList; import java.util.List; // 辅助类 class Item{ String value; boolean isNumber; public Item(String value,boolean isNumber){ this.value=value; this.isNumber=isNumber; } public Item(char c,boolean isNumber){ this.value=String.

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

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