妈妈说我，从小记性就很差，什么东西都要记下来才行。html
现象描述: 环境是 .NET 4.0,数据库是SQL2008,存储过程在数据库中执行很快，可是使用代码调用时异常的缓慢。数据库操做类代码是使用 Microsoft.Practices.EnterpriseLibrary.Data.Database.GetStoredProcCommand 建立 StoredProcedure 类型 Commond 对象,而后使用 ExecuteDataSet 方法执行的。数据库
1). 发生某一个存储过程执行异常缓慢，而其它的'小伙伴'都很正常。c#
（排除数据库瞬间压力的可能）有时候发生这种没法解释的问题，大都是人品问题。通常处理方法就是Drop 掉存储过程或者 Recomplie (语法: exec sp_recompile @objname='存储过程的名字')一下。若是这个还不行，恭喜你能够玩一下' 删空格' 游戏了。有时候咱们会发现查询语句中多了意外的全角空格会致使查询错误或者执行异常，因此无论什么空格，把多余的全删除下，从新执行也许就顺利经过了。固然这个不必定适用你的状况，没办法的时候只能死马全当活马医了。缓存
2)若是广泛或者较多的存储过程都出现这种让人纠结的问题。框架
应该考虑是否是哪里疏忽了，由于咱们在作测试的时候可能传入了和程序中不同的限制条件致使的。一开始我也不相信本身会犯这样的错误，可是当我去检查代码的时候发现，原来本身推测的传入参数太‘天真’了（说实话咱们项目组刚发生了这样的状况，搞的一星期都是在开会研究确认这个问题，而后向总部提交了疑难问题，结果在第二周的时候发现原来咱们都天真了一把。）。因此仍是要检查一下代码确认本身已经很纯洁了，再来考虑是否是代码框架发生了问题。测试
ASP.NET调用SQL后台存储过程时，有时忽然就变得很慢，在后台直接执行存储过程没问题，但在前台调用存储过程时就是很慢，并且在前台调用成功后，再次调用仍是同样的慢，但更新一下存储过程再调用就很快了。但这始终不能完全解决问题，过段时间又会出来一样的问题。优化
若是断定是缓存的问题解决办法能够参考下面的方法:.net
方法一：在可能比较耗时的语句后面加上option(recompile)code
方法二：强制编译存储过程htm
SQL Server 提供三种从新编译存储过程的方法：
(1)、sp_recompile 系统存储过程强制在下次运行存储过程时进行从新编译。
示例：exec sp_recompile 存储过程名
(2)、建立存储过程时在其定义中指定 WITH RECOMPILE 选项，代表 SQL Server 将不对该存储过程计划进行高速缓存；该存储过程将在每次执行时都从新编译。
示例：Create Proc 存储过程名 WITH RECOMPILE AS 参数
(3)、在执行存储过程时指定 WITH RECOMPILE 选项，可强制对存储过程进行从新编译。仅当所提供的参数不典型，或者自建立该存储过程后数据发生显著更改时才应使用此选项。
示例：存储过程名 WITH RECOMPILE
若是没法断定是缓存引发的能够试试下面的这样办法:
把执行Procedure 的参数直接拼好传递给查询语句执行代替从代码中直接调用存储过程。
建立 CommandType = CommandType.Text 的 DbCommand 对象,再调用
<!-- lang: c# -->
ExecuteDataSet("EXEC PRO_SFDAB008_QUERY '',null,'2009-01-01','2014-01-01' ");
把执行Procedure 的参数直接拼好传递。
上面的方法不必定管用，可是在没有办法的时候试一试老是能够的。
百度参考： SQL优化之存储过程强制编译