22,209
社区成员
发帖
与我相关
我的任务
分享存储过程在SQL Server Management Studio执行很快，但在C#中调用巨慢
项目中用到一个存储过程，在SQL Server Management Studio执行很快，如下图所示：
由上图可以看出调用时间为0秒
但是在C#中调用就巨慢，如下图所示：
由图中可以看出，所用的数据库、执行语句完全一样，但执行“adp.Fill(ds)”这一句时用了100秒！
public DataTable query(string sqlstr)
{
using (SqlConnection con = new SqlConnection(DBHelper.sqlConnection))
{
SqlDataAdapter adp = new SqlDataAdapter(sqlstr, con);
adp.SelectCommand.CommandTimeout = 180000;
DataTable ds = new DataTable();
DateTime timestart = DateTime.Now;
adp.Fill(ds);
DateTime timeend = DateTime.Now;
return ds;
}
}
这两个差异太大了，求高手协助分析原因
由上图可以看出调用时间为0秒
但是在C#中调用就巨慢，如下图所示：
由图中可以看出，所用的数据库、执行语句完全一样，但执行“adp.Fill(ds)”这一句时用了100秒！
public DataTable query(string sqlstr)
{
using (SqlConnection con = new SqlConnection(DBHelper.sqlConnection))
{
SqlDataAdapter adp = new SqlDataAdapter(sqlstr, con);
adp.SelectCommand.CommandTimeout = 180000;
DataTable ds = new DataTable();
DateTime timestart = DateTime.Now;
adp.Fill(ds);
DateTime timeend = DateTime.Now;
return ds;
}
}
这两个差异太大了，求高手协助分析原因
...全文
请发表友善的回复…
发表回复
哎呦喂-腰疼 2018-05-02
- 打赏
- 举报
9楼正解 ，不过我不是每次执行存储过程就重新编译，我是执行久了之后执行
USE AdventureWorks2012;
GO
EXEC sp_recompile N'存储过程名称';
GO
重新编译存储过程
小小的老大 2017-01-12
- 打赏
- 举报
楼主解决问题了吗？我最近也遇到了一样的问题，但不知道怎么解决
LongRui888 2016-01-26
- 打赏
- 举报
如果这个存储过程执行次数不是太频繁，建议直接在exec 时加上 with recompile，在每次调用都重新编译。
我觉得这个还是存储过程的执行计划导致的，存储过程的好处是编译一次，运行多次，执行计划被保留下来，减少了每次执行的编译时间，但坏处是执行计划相对是固定的。
当你的数据不断变化的时候，实际上也需要执行计划不断变化，而这一点又和存储过程本身固定的执行计划相互冲突，所以这个时候建议每次运行都编译，虽然编译会消耗时间，但是至少消耗的时间要比最慢的执行时间100s要小的多
zhanghong1peng 2016-01-26
- 打赏
- 举报
7楼描述的有点歧义，我想表述的是，存储过程没有编绎不管用SqlDataAdapter 还是用SqlCommand 都很慢，需要一分多种；
存储过程编绎后这两种方式都可以一秒钟出结果。
Tiger_Zhao 2016-01-26
- 打赏
- 举报
SqlDataAdapter 可能内部有什么“优化”，决定什么时候可以用现成的执行计划，什么时候要临时编译。
都是微软自己的东西，这个就没法猜了。
都是微软自己的东西，这个就没法猜了。
zhanghong1peng 2016-01-26
- 打赏
- 举报
回复5楼：
有直接用SqlCommand 试过，在没有重新编绎之前也是一样的需要一分多钟。
重新编绎之后，现调试也是也是一秒就可以得到结果。
但我觉得应该是重新编绎触发了什么造成了速度快起来的（个人觉得可能是参数嗅探）。
Tiger_Zhao 2016-01-26
- 打赏
- 举报
你直接给个 exec 的语句，解析在服务端，SqlDataAdapter 根本不知道返回结果是什么，估计需要多次尝试才能填充出正确的 DataTable。
试试用 SqlCommand 来指向存储过程：C#调用存储过程简单完整例子
试试用 SqlCommand 来指向存储过程：C#调用存储过程简单完整例子
xiaoxiangqing 2016-01-26
- 打赏
- 举报
我也遇到过这种情况，没找到原因
zhanghong1peng 2016-01-26
- 打赏
- 举报
@KanzakiOrange 没有用到链接服务器。
@x_wy46 数据库服务启用了TCP/IP。
这个存储过程重新编绎了一下后速度马上就起来了。
后来我检查了一下，并没有做“参数嗅探”方面的防控，参数是直接使用；这个存储过程已经用了三年了，很有要能是参数嗅探造成的这么慢，但怪就怪在用SQL Server Management Studio执行很快，这个很难理解。
zhanghong1peng 2016-01-26
- 打赏
- 举报
我决定再看一段时间，如果还是这个问题，请加上“WITH RECOMPILE”选项再进行观查。
吉普赛的歌 2016-01-26
- 打赏
- 举报
ALTER PROCEDURE [dbo].[Proc_test]
WITH RECOMPILE
Ginnnnnnnn 2016-01-21
- 打赏
- 举报
看下存储过程里面是否用到链接服务器。如果是的话改成临时表进行缓存处理
专注or全面 2016-01-21
- 打赏
- 举报
参数一样首先就可以排除参数嗅探问题
你连接的数据库服务是否启用了TCP/IP
