标签:
对于做管理系统和分析系统的程序员,复杂SQL语句是不可避免的,面对海量数据,有时候经过优化的某一条语句,可以提高执行效率和整体运行性能。如何选择SQL语句,本文提供了两种方法,分别对多条SQL进行量化的分析。
在测试SQL性能的过程中。
一是通过设置STATISTICS查看执行SQL时的系统情况。选项有PROFILE,IO ,TIME。
SET STATISTICS PROFILE ON:显示分析、编译和执行查询所需的时间(以毫秒为单位)。
SET STATISTICS IO ON:报告与语句内引用的每个表的扫描数、逻辑读取数(在高速缓存中访问的页数)和物理读取数(访问磁盘的次数)有关的信息。
SET STATISTICS TIME ON:显示每个查询执行后的结果集,代表查询执行的配置文件。
实例如下:
SET STATISTICS PROFILE ON SET STATISTICS IO ON SET STATISTICS TIME ON GO --你的SQL脚本开始 select top 100 * from TBL_Cot_RecStaticList --你的SQL脚本结束 GO SET STATISTICS PROFILE OFF SET STATISTICS IO OFF SET STATISTICS TIME OFF
显示信息:
SQL Server 分析和编译时间: CPU 时间 = 0 毫秒,占用时间 = 59 毫秒。 (100 行受影响)
表 ‘TBL_Cot_RecStaticList‘。扫描计数 1,逻辑读取 14 次,物理读取 2 次,预读 992 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。 SQL Server 执行时间: CPU 时间 = 0 毫秒,占用时间 = 306 毫秒。 SQL Server 分析和编译时间: CPU 时间 = 0 毫秒,占用时间 = 1 毫秒。 SQL Server 执行时间: CPU 时间 = 0 毫秒,占用时间 = 1 毫秒。 SQL Server 执行时间: CPU 时间 = 0 毫秒,占用时间 = 1 毫秒。
另外,也可以通过手工添加语句,计算执行时间来查看执行语句花费了的时间,以判断该条SQL语句的效率如何:
declare @d datetime set @d=getdate() --你的SQL脚本开始 SELECT [TestCase] FROM [TestCaseSelect] --你的SQL脚本结束 select [语句执行花费时间(毫秒)]=datediff(ms,@d,getdate())
二是通过SQL 2008的“查询”按钮下的“包括实际的执行计划”和“包括客户端统计信息”。
下面是我和经理写的两个例子的性能对比:
我的:
SQL Server 执行时间:
CPU 时间= 32 毫秒,占用时间= 762 毫秒。
CPU 时间= 16 毫秒,占用时间= 475 毫秒。
CPU 时间= 32 毫秒,占用时间= 671 毫秒。
CPU 时间= 31 毫秒,占用时间= 615 毫秒。
经理的:
SQL Server 执行时间:
CPU 时间= 16 毫秒,占用时间= 547 毫秒。
CPU 时间= 47 毫秒,占用时间= 491 毫秒。
CPU 时间= 32 毫秒,占用时间= 436 毫秒。
CPU 时间= 47 毫秒,占用时间= 416 毫秒。
PS:今天在做一道题目的时候,经理给出的一道难题,虽然做出来了,但是性能没有做到最优化。其中用到了三层嵌套。现在特别是要总结的:大表跟小表进行关联查询 时,涉及到嵌套查询,先查询小表,然后再联合大表。我是一开始让大小表进行关联,然后再嵌套。而经理写的是先让小表嵌套,最后在关联。这样,执行效率自然要比我高
标签:
原文地址:http://www.cnblogs.com/zouhao/p/4283738.html