SQL Server中ISNULL函数个人总结

写这篇博客主要是最近在做项目的时候碰到了一个很奇怪的现象：执行了一个存储过程，返回结果大概有3000行左右，但却用了40几秒的时间，实在让我很郁闷，于是我详细看了下脚本，经过多次的修改测试以后，居然发现是因为在WHERE子句中使用了ISNULL函数，这个还不是最关键的，关键是我居然给对一个不可能为NULL的参数进行了NULL值判断（也就是使用了ISNULL函数），然后我把这些不必要的ISNULL函数去掉以后，再次执行之后返回结果就只用了0秒，经过思考后我才发现，对一个不可能为NULL的参数进行判断就好比是画蛇添足，经过思考后，对ISNULL函数总结了以下几点：

 1.在给变量赋值的时候不需要ISNULL的判断，应该在计算时使用到该变量的时候再加上ISNULL的判断

select   @OldMQuan =   ISNULL   ( MQuan ,   0 ), @OldPQuan   =   ISNULL ( AQuantity   , 0 )

from  TableName

where   Id = ISNULL (   @Id , 0   )

 

这里的ISNULL (MQuan, 0)和ISNULL(AQuantity ,0)完全是可以省略掉的，

 而在使用的时候应该加上，如下:

update  TableName

set   RQuan   = isnull (  RQuan  , 0   )   -   isnull   ( @OldPQuan  ,   0 )   +   isnull   ( @OldMQuan ,   0 )

where  Id=ISNULL( @Id,0 )                          

 

2.WHERE子句中应避免使用ISNULL等函数，应该在存储过程开始时就对参数进行ISNULL的判断

如下：

update  TableName

set   RQuan   = isnull (  RQuan  , 0   )   -   isnull   ( @OldPQuan  ,   0 )   +   isnull   ( @OldMQuan ,   0 )

where  Id=ISNULL( @Id,0 )     

可以改为在存储过程刚开始的就对参数进行NULL值判断，接着在下面的脚本中就可以直接使用该变量，而不用再重复多次去判断参数NULL值得情况了：

上面的就可以改为如下的写法：

set @Id=ISNULL( @Id,0 ) 

 

update  TableName

set   RQuan   = isnull (  RQuan  , 0   )   -   isnull   ( @OldPQuan  ,   0 )   +   isnull   ( @OldMQuan ,   0 )

where  Id= @Id   

 

3WHERE子句中ISNULL()的使用，让该表达式等同于1=1，使其失效的处理方式优化：

DECLARE @myID INT

SET @myID=NULL

SELECT * FROM TABLENAME

WHERE ID=ISNULL(@myID,ID)

AND ... AND .....

 处理方法：

where id=isnull(@myid,id)改为

where (@myid is not null and id=@myid) or (@myid is null）

 

4.UPDATE更新数量的时候需要对数量进行运算时需判断数据库表中字段的值是否为NULL值：

update  TableName

set   CQuan   =   ISNULL ( CQuan   , 0 )   -   ISNULL ( @MQuan , 0 )

where   id =   @id   and   ISNULL   ( CQuan ,   0 )   -   ISNULL   ( @Quan ,   0 )   >=   0

 

如果上面语句中在表当中这个CQuan字段定义为可空的话，就需要加上ISNULL(CQuan ,0)这个判断了

 

同时还应该加上（）以区分表达式的范围， 如下：

update  TableName

set   CQuan   =   ISNULL ( CQuan   , 0 )   -   ISNULL ( @MQuan , 0 )

where   id =   @id   and  （  ISNULL   ( CQuan ,   0 )   -   ISNULL   ( @Quan ,   0 )  ） >=   0

 

转载于:https://www.cnblogs.com/buguangchao/archive/2013/04/28/3050059.html