none
通过asp.net,C#查询sql2005超时 RRS feed

  • 问题

  • 查询方法主要代码如下:

     DataTable dt = new DataTable("table1");

            using (SqlConnection con = new SqlConnection(CONNECTION_STRING))
            {
                using (SqlCommand com = new SqlCommand())
                {
                    com.CommandText = "procedurename";
                    com.CommandType = CommandType.StoredProcedure;

                   //设置参数省略.......
                    com.Connection = con;
                    con.Open();
                    SqlDataAdapter da = new SqlDataAdapter(com);
                    //da.SelectCommand.CommandTimeout = 1200;   
                    da.Fill(dt);
                    //SqlDataReader rd = com.ExecuteReader();
                }
            }

    如果不设置SelectCommand.CommandTimeout 这个就会在Fill或者ExecuteReader的时候超时(默认30秒),用SqlDataReader 也一样。但是直接在sql2005里执行存储过程procedurename返回结果很快,1秒不到。返回的结果集不大,50多行,10列左右(通过行列转换,列数不定)。虽然可以设置SelectCommand超时时间得到结果,但是因为太慢,感觉这么点数据不会这么慢。请教各位高手,是什么原因,有什么解决方法?谢谢!

     

    2008年5月5日 7:23

答案

  •  

    还有问题,原来存储过程里EXEC sp_executesql @sql;这就话后面是带参数的,后来不用对@sql传参数了,但是没有删除后面的参数而是直接注释了,像这样

    EXEC sp_executesql @sql --,N'@RegionID int,@StoreID varchar(30),@Year int,@bMonth int,@eMonth int,@dayPart nvarchar(50)'
     -- ,@RegionID,@StoreID,@Year,@bMonth,@eMonth,@dayPart

     

    把后面注释掉删了就好了,不知道为什么。

    2008年5月8日 4:15

全部回复

  •  

    不应该超时,仔细检查传递的参数是否都正确
    2008年5月5日 7:35
    版主
  • 设置参数代码如下:

    com.Parameters.AddWithValue("@RegionID", (regoinid == "%"  || string.IsNullOrEmpty(regoinid)) ? Convert.DBNull : (object)Convert.ToInt32(regoinid));
                    com.Parameters.AddWithValue("@StoreID", (storeid == "%" || string.IsNullOrEmpty(storeid)) ? Convert.DBNull : (object)storeid);
                    com.Parameters.AddWithValue("@Year", Convert.ToInt32(year));
                    com.Parameters.AddWithValue("@bMonth", Convert.ToInt32(bmonth));
                    com.Parameters.AddWithValue("@eMonth", Convert.ToInt32(emonth));
                    com.Parameters.AddWithValue("@dayPart", string.IsNullOrEmpty(dayPart) ? Convert.DBNull : (object)dayPart);

     

    存储过程的参数如下:

    @RegionID int,
     @StoreID varchar(30),
     @Year int,
     @bMonth int,
     @eMonth int,
     @dayPart nvarchar(50)

     

    查询可以得到结果,就是Fill的时候太慢了。

    2008年5月5日 7:55
  •  

    @RegionID int,
     @StoreID varchar(30),

    @dayPart nvarchar(50)三个参数的值写死测试一下看看。

     

    比如

    com.Parameters.AddWithValue("@RegionID",20);

     

    2008年5月5日 8:07
    版主
  • 指定值是可以快一点,但是要所有的怎么处理呢?我在存储过程中判断是否null来看是否指定参数值。

     

    2008年5月5日 8:39
  • 试试

    System.DBNull.Value

    2008年5月5日 9:08
    版主
  • 试过了 ,还是超时。

    2008年5月6日 1:19
  • 谢谢孟大哥的关注,麻烦你了,问题我找到了,是因为sql语句的问题。

    在sql server 2005里执行存储过程后,消息窗口有这么一句话“警告: 聚合或其他 SET 操作消除了空值。”。

    ADO.net可能因为这个警告导致出结果很慢,虽然在sql server里执行没什么问题。

    原因是sum里面没有isnull一下。改了一下sql语句就好了。

    2008年5月6日 1:55
  • DEBUG一下。Fill方法。计算出时间差

    2008年5月6日 18:22
  •  

    还有问题,原来存储过程里EXEC sp_executesql @sql;这就话后面是带参数的,后来不用对@sql传参数了,但是没有删除后面的参数而是直接注释了,像这样

    EXEC sp_executesql @sql --,N'@RegionID int,@StoreID varchar(30),@Year int,@bMonth int,@eMonth int,@dayPart nvarchar(50)'
     -- ,@RegionID,@StoreID,@Year,@bMonth,@eMonth,@dayPart

     

    把后面注释掉删了就好了,不知道为什么。

    2008年5月8日 4:15
  • 这个神奇的问题我也碰到了,虽然也包含了聚合,但是执行存储过程执行没有任何消息错误, 还是会超时,甚至注释了里面的所有语句,都会超时,但是改成单一的select语句,就又不超时了。然后恢复原来的语句,居然可以了。只是好景不长,早上可以的到下午后什么都没有动过,又开始提示超时了。真是神奇的Sql呀。。。。。。。 超时的时候,我用sql的企业管理器运行还是很正常的。1秒都不用就出来了,而且没有任何错误消息提示。

    晕呀!。。。

    刚刚突发奇想,将原来的输入参数又 DateTime类型改为nvarchar(10),居然又可以了。 希望不要像之前哪样,好一会就完了。。。。

    2012年3月10日 10:14
  • 这个神奇的问题我也碰到了,虽然也包含了聚合,但是执行存储过程执行没有任何消息错误, 还是会超时,甚至注释了里面的所有语句,都会超时,但是改成单一的select语句,就又不超时了。然后恢复原来的语句,居然可以了。只是好景不长,早上可以的到下午后什么都没有动过,又开始提示超时了。真是神奇的Sql呀。。。。。。。 超时的时候,我用sql的企业管理器运行还是很正常的。1秒都不用就出来了,而且没有任何错误消息提示。

    晕呀!。。。

    刚刚突发奇想,将原来的输入参数又 DateTime类型改为nvarchar(10),居然又可以了。 希望不要像之前哪样,好一会就完了。。。。

    晕了,终于在1周后再次出现该问题,到底是啥原因哦。。。。。。。。
    • 已建议为答案 Ocean in GZ 2012年3月16日 6:42
    • 取消建议作为答案 Ocean in GZ 2012年3月16日 6:42
    2012年3月16日 3:27
  • 这个神奇的问题我也碰到了,虽然也包含了聚合,但是执行存储过程执行没有任何消息错误, 还是会超时,甚至注释了里面的所有语句,都会超时,但是改成单一的select语句,就又不超时了。然后恢复原来的语句,居然可以了。只是好景不长,早上可以的到下午后什么都没有动过,又开始提示超时了。真是神奇的Sql呀。。。。。。。 超时的时候,我用sql的企业管理器运行还是很正常的。1秒都不用就出来了,而且没有任何错误消息提示。

    晕呀!。。。

    刚刚突发奇想,将原来的输入参数又 DateTime类型改为nvarchar(10),居然又可以了。 希望不要像之前哪样,好一会就完了。。。。

    晕了,终于在1周后再次出现该问题,到底是啥原因哦。。。。。。。。

    终于知道了问题在哪里了, 原来是其中一个语句使用了View来做聚合计算(这个View记录比较多30万条左右吧,通过多张表连接而来),而在这个聚合的数据筛选范围用了一个in ( select() )的语句,里面的Select () 来源一个自己定义的function,其实就是动态对字符aa;bb;cc;等等分拆成表结果的形式,导致整个运行超时了。反而我直接将字符放上去就很快取到 例如:in(aa,bb,cc,...) 改成拼接sql字串,然后 exec(@sql)的方式,问题就解决了。

    不过唯一不解的是之前一直超时一直都是执行的很快的。这次超时就是在后台企业管理器运行就不快了。才让我进行一行一行代码的Debug. 希望这个是真正的问题所在了。 希望这个Case对大家有帮助。

    2012年3月16日 6:54