TOP语句放到表值函数外,效率异常低下的原因分析
2011-04-27 13:32
225 查看
SQLSERVER的表值函数是SQLSERVER 2005以来的新特性,由于它使用比较方便,就像一个单独的表一样,在我们的系统中大量使用。有一个获取客户数据的SQLSERVER 表值函数,如果使用管理员登录,这个函数会返回150W行记录,大概需要30秒左右,但如果将TOP语句放到表值函数外,效率异常低下,需要约3分钟:
select top 20 * from GetFrame_CustomerSerch('admin','1')
下面是该存储过程的定义:
ALTER FUNCTION [dbo].[GetFrame_CustomerSerch]
(
-- Add the parameters for the function here
@WorkNo varchar(38)
,@SerchChar varchar(500)
)
RETURNS TABLE
AS
RETURN
(
-- Add the SELECT statement with parameter references here
select a.GUID,a.CustomerName,a.CustomerIDcard,a.CustomerPhone,a.CustomerMobile from
(
--具体子查询略
)
) a union all
select b.GUID,b.CustomerName,b.CustomerIDcard,b.CustomerPhone,b.CustomerMobile from WFT_ManagerCollectUsers a left join WFT_Customer b on a.FundAccount=b.FundAccount
--where a.WorkNo=@WorkNo
WHERE a.WorkNo IN
(
--具体子查询略
)
)
这个语句放在PDF.NET数据开发框架的SQL-MAP文件中,开始还以为是框架引起的,将这个语句直接在查询分析器中查询,仍然很慢。
将GetFrame_CustomerSerch 中的SQL语句提取出来,直接加上Top查询,只需要6秒,快了N倍:
declare @WorkNo varchar(38)
declare @SerchChar varchar(500)
set @WorkNo='admin'
set @SerchChar='1'
select top 20 a.GUID,a.CustomerName,a.CustomerIDcard,a.CustomerPhone,a.CustomerMobile from
(
--具体子查询略
)
) a union all
select b.GUID,b.CustomerName,b.CustomerIDcard,b.CustomerPhone,b.CustomerMobile from WFT_ManagerCollectUsers a left join WFT_Customer b on a.FundAccount=b.FundAccount
WHERE a.WorkNo IN
(
--具体子查询略
)
为什么会有这么大的差异?
我分析可能有如下原因:
1,在表值函数外使用Top或者其它条件,SQLSERVER 的查询优化器无法针对此查询进行优化,比如先返回所有记录,然后再在临时表中选取前面的20条记录;
2,虽说该表值函数使用了“表变量”,它是内存中的,但如果这个“表”结果很大,很有可能内存放不下(并非还有物理内存就会将结果放到物理内存中,数据库自己还会有保留的,会给其它查询预留一定的内存空间),使用虚拟内存,而虚拟内存实际上就是磁盘页面文件,当记录太多就会发生频繁的页面交换,从而导致这个查询效率非常低。
看来,“表值函数”也不是传说中的那么好,不知道大家是怎么认为的。
最近还遇到一个怪异的问题,有一个存储过程,老是在系统运行1-2天后变得极其缓慢,但重新修改一下又很快了(只是加一个空格之类),不知道大家遇到过没有,什么原因?
select top 20 * from GetFrame_CustomerSerch('admin','1')
下面是该存储过程的定义:
ALTER FUNCTION [dbo].[GetFrame_CustomerSerch]
(
-- Add the parameters for the function here
@WorkNo varchar(38)
,@SerchChar varchar(500)
)
RETURNS TABLE
AS
RETURN
(
-- Add the SELECT statement with parameter references here
select a.GUID,a.CustomerName,a.CustomerIDcard,a.CustomerPhone,a.CustomerMobile from
(
--具体子查询略
)
) a union all
select b.GUID,b.CustomerName,b.CustomerIDcard,b.CustomerPhone,b.CustomerMobile from WFT_ManagerCollectUsers a left join WFT_Customer b on a.FundAccount=b.FundAccount
--where a.WorkNo=@WorkNo
WHERE a.WorkNo IN
(
--具体子查询略
)
)
这个语句放在PDF.NET数据开发框架的SQL-MAP文件中,开始还以为是框架引起的,将这个语句直接在查询分析器中查询,仍然很慢。
将GetFrame_CustomerSerch 中的SQL语句提取出来,直接加上Top查询,只需要6秒,快了N倍:
declare @WorkNo varchar(38)
declare @SerchChar varchar(500)
set @WorkNo='admin'
set @SerchChar='1'
select top 20 a.GUID,a.CustomerName,a.CustomerIDcard,a.CustomerPhone,a.CustomerMobile from
(
--具体子查询略
)
) a union all
select b.GUID,b.CustomerName,b.CustomerIDcard,b.CustomerPhone,b.CustomerMobile from WFT_ManagerCollectUsers a left join WFT_Customer b on a.FundAccount=b.FundAccount
WHERE a.WorkNo IN
(
--具体子查询略
)
为什么会有这么大的差异?
我分析可能有如下原因:
1,在表值函数外使用Top或者其它条件,SQLSERVER 的查询优化器无法针对此查询进行优化,比如先返回所有记录,然后再在临时表中选取前面的20条记录;
2,虽说该表值函数使用了“表变量”,它是内存中的,但如果这个“表”结果很大,很有可能内存放不下(并非还有物理内存就会将结果放到物理内存中,数据库自己还会有保留的,会给其它查询预留一定的内存空间),使用虚拟内存,而虚拟内存实际上就是磁盘页面文件,当记录太多就会发生频繁的页面交换,从而导致这个查询效率非常低。
看来,“表值函数”也不是传说中的那么好,不知道大家是怎么认为的。
最近还遇到一个怪异的问题,有一个存储过程,老是在系统运行1-2天后变得极其缓慢,但重新修改一下又很快了(只是加一个空格之类),不知道大家遇到过没有,什么原因?
相关文章推荐
- TOP语句放到表值函数外,效率异常低下
- SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理
- SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理
- sql语句的优化分析之一查询语句中左连接和函数效率分析比较
- Javascript 字符串字节长度计算函数代码与效率分析(for VS 正则)
- 在Android library中不能使用switch-case语句访问资源ID的原因分析及解决方案
- Eclipse相关错误导致web项目发布异常问题原因分析及解决方案
- 简述项目中优化sql语句执行效率的方法,从哪些方面,sql语句性能如何分析?
- jvm_bind端口占用异常原因分析
- 分析curl错误原因的函数curl_error
- 在Android library中不能使用switch-case语句访问资源ID的原因分析及解决方案
- [Oracle]高效的SQL语句之分析函数(二)--max()
- Oracle应用专题之:分析函数3(Top/Bottom N、First/Last、NTile)
- java.lang.NoClassDefFoundError异常原因分析
- mysql中提高Order by语句查询效率的两个思路分析
- SQL语句汇总-分析函数
- zabbix运行久了以后效率会变慢的原因分析
- 找出执行效率低下的sql语句
- 在Activity的onCreate方法中显示PopupWindow导致异常的原因分析及解决方案
- SQL语句执行效率及分析(note)