参数化查询速度慢，参数化速度慢

参数化查询速度慢，参数化速度慢

好累，加班到现在，但是其实你的负责的工作都已经做完了。可是还需要配合别人，只能等！！！  现在已经凌晨了。。。

工作分配不够好？个人不负责？时间规划不好？

不知道！！！

说入正题，这是问题原型：

 --SQL1
 declare @OrderDetailID nvarchar(50)
 set @OrderDetailID='R1502003963580C001'
 select * from BillDetail where OrderDetailID=@OrderDetailID 
 --SQL2
 select * from BillDetail where OrderDetailID='R1502003963580C001' 
 

其实我查询了好长时间的资料没查出来什么原因？（连重现都重现不了，是之前记下的问题，引以为戒，每次发现问题需要具体记下来。。。忙了这么就一点收获都没有）
我只想说我以后要用第二种。。。哪位大牛帮帮忙

PS：另外在每次使用SqlParameter时，如果是字符类型的，都尽量加上size，涉及到执行计划缓存的问题

          例如：new SqlParameter("@name", SqlDbType.Varchar, 40) { Value = name };




反正还是不能下班。。。

我又查了一下：好像微软官方也出现过这样的问题

给出的解决方案是这样的：The only resolution to this problem is to use a stored querydef query instead of prepared queries.

也许可以这么理解（用存储过程的形式）：

将上面的参数化改为这样： exec('select * from BillDetail where OrderDetailID='''+@OrderDetailID+'''')

暂且就这样吧！主要是现在不能重现，无法验证，如果遇到了，这样先试一下咯

还是不能下班。。。，已经快凌晨2点了，我觉得我需要考虑考虑换换工作的事了

就又查询了下，参考了这个博客http://www.cnblogs.com/fxwdl/archive/2013/01/09/1257409.html

是由于定义的字符串类型不匹配造成的

declare @OrderDetailID varchar(50)  --从nvarchar变为varchar

着急查出问题的朋友直接看下面就好了。。。

总结一下：

执行速度较慢的这句执行计划如下：

 declare @OrderDetailID nvarchar(50)
   set @OrderDetailID='R1502003963580C001'
   select * from BillDetail where OrderDetailID=@OrderDetailID   

 解决办法有两种：

 1.使用执行存储过程的方式

 declare @OrderDetailID1 nvarchar(20)
   set @OrderDetailID1='R1502003963580C001'
   exec('select * from BillDetail where OrderDetailID='''+@OrderDetailID1+'''')

2.定义正确的参数类型

 declare @OrderDetailID2varchar(20)
   set @OrderDetailID1='R1502003963580C001'
   select * from BillDetail where OrderDetailID=@OrderDetailID2

   

所以呢，应该算是解决了吧！！！没白忙活，可是还是没有下班，某酒店行业的IT部真是逗。。。