为啥同一个查询,做成函数反而慢了呢

Question

本帖最后由 u013478753 于 2014-01-16 19:50:13 编辑

Answer 1

可是我整个函数里只用了一个表变量就是@ret 就是函数的返回值, 而且因为是统计数据,记录数并不多,

Answer 2

可是我整个函数里只用了一个表变量就是@ret 就是函数的返回值, 而且因为是统计数据,记录数并不多,哦，那这样，你把执行计划贴出来看看把

Answer 3

我发现了一个新的现象
比如
有表 table1(col1 varchar(10),col2 varchar(10)) 并且col1和col2都有独立索引(不是组合索引)
declare @v_col1 varchar(10),@v_col2 varchar(10)
select @v_col1 = '123',@v_col2 = null
select * from table1 
where (@v_col1 is null or rtrim(@v_col1) = '' or col1 = @v_col1) --参数为空表示所有
   and (@v_col2 is null or rtrim(@v_col2) = '' or col2 = @v_col2)可以看出由于@v_col2 值是null 所以虽然写了or col2 = @v_col2,但是这个条件是不会发挥作用的,也不会增加查询耗时神奇的是我把这一整行"不会影响查询速度的条件"给删掉变成下面的样子
declare @v_col1 varchar(10),@v_col2 varchar(10)
select @v_col1 = '123',@v_col2 = null
select * from table1 
where (@v_col1 is null or rtrim(@v_col1) = '' or col1 = @v_col1) --参数为空表示所有
结果居然是查询耗时增加了,注意是增加了而不是减少了,也就是说,加一个"无耗时"的条件以后,查询速度反而加快
耗时增加以后,查询分析器的耗时变的和用函数查询的耗时相同了,真是汗
我去函数里也把这一整行给备注掉(因为我在测试的时候这个参数就是传null的 比如 select * from f_a('123',null) )
结果函数的耗时没有任何变化

Answer 4

那我就不懂了,表值函数要受到比存储过程多的限制(只能做只读操作),然后还比存储过程慢,那它存在的意义是什么有意义，就是能这么查询,还能关联：select * from dbo.表值函数(参数)而存储过程，只能这样：exec 存储过程 参数

Answer 5

执行计划主要检查开销COST的大小和开销百分比%（注：线条粗细也是比较直观的），如果偏大就说明有tuning的空间，可以调整写法，合理使用索引，再查看执行计划开销的变化。