字符串 和 SqlParameter 查询效率问题,比较难解决的问题。

时间:2023-01-04 19:52:50
第一种 

StringBuilder strSql = new StringBuilder();


            strSql.Append(@"
select GameKey  as  [GameKey],max(GameName) as [GameName],COUNT(1) as  [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from   RegInfo where PostTime between '" + BeginTime.ToString() + "' and '" + EndTime.ToString() + "' ");
 strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");


第二种
      StringBuilder strSql = new StringBuilder();


            strSql.Append(@"
select GameKey  as  [GameKey],max(GameName) as [GameName],COUNT(1) as  [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from   RegInfo ");

  strSql.Append("where  PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
                    new SqlParameter("@BeginTime", SqlDbType.DateTime),
                    new SqlParameter("@EndTime", SqlDbType.DateTime)}


居然第二种执行出来超时,但在查询分析器里执行出来效率却是一样的,都在1秒多(这个表里有3百多万条数据).
而且,第二种方法我不加PostTime也可以成功执行。
我想有可能是DateTime的原因,但不知道怎么解决。

50 个解决方案

#1


1、貌似两句sql不一样,后者缺少group
2、如果一样,查询分析器是一样的,因为只是分析语句,加参不加参,对性能影响不大,除非太多

#2


SqlDbType.DateTime这是日期格式
BeginTime.ToString是字符串形式
你这两个结果一样吗?

#3


引用 1 楼 jiuhexuan 的回复:
1、貌似两句sql不一样,后者缺少group
2、如果一样,查询分析器是一样的,因为只是分析语句,加参不加参,对性能影响不大,除非太多


1."后者缺少 group "是因为我复制上来的时候少复制了一句,两句SQL都加了group by 的。
2.参数查询只加了一个日期,没加其它的了。通过跟踪出来的语句,然后在查询分析器里执行,效率都是一样的,但就是通过c#程序执行的时候,第二种写法报错(超时)。

#4


引用 2 楼 bdmh 的回复:
SqlDbType.DateTime这是日期格式
BeginTime.ToString是字符串形式
你这两个结果一样吗?


 public DataSet GetRegInfoGameList(DateTime BeginTime, DateTime EndTime)
传入参数的类型肯定是一样的。
你所说的两个类型肯定是不一样的,不是都推荐用  SqlParameter  来写吗?
如果可以用字符串拼接的方式来写,我不这么头痛了。


对了,我的环境是 Win7(64位操作系统),VS2010(.net 4.0)+SQL2008

#5


这两个怎么能扯到一块呢

#6


唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”

#7


引用 5 楼 hualilihua 的回复:
这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?

#8


引用 6 楼 hualilihua 的回复:
唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。

#9


估计你数据库里面PostTime字段是不是smalldatetime类型?

#10


引用 6 楼 hualilihua 的回复:
唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”


实在不明白,您这句话,和我这个代码错误有什么关联。

#11


引用 9 楼 jiangshun 的回复:
估计你数据库里面PostTime字段是不是smalldatetime类型?


谢谢,jiangshun 的回复,我开始也以为是和数据库里字段类型不匹配,核对了三次,确实是datetime 
长度为8位的那种,也不是datetime2(7).

#12



StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo ");
strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)}
}
//没有看到参数的值 啥的

lz把代码贴全了瞧瞧

#13


引用 7 楼 x2670316290 的回复:
引用 5 楼 hualilihua 的回复:

这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?


两个效率没有高低的说法,我估计是你数据库里面的字段类型和声明参数的时候字段类型不一样
比如数据库是varchar类型的
在SqlParameter(string parameterName, object value)时候,没有指明具体的类型,所以,默认的就成了nvarchar类型的,在数据量过KW的时候就会出现和varchar类型速度上的区别

#14


引用 12 楼 yanbuodiao 的回复:
C# code


StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.……

或者你在指定值的时候 先把那俩字串 转成DataTime类型的试试 不应该有这种问题的

#15


引用 12 楼 yanbuodiao 的回复:
C# code

StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.Clear……




 public DataSet GetRegInfoGameList(DateTime BeginTime, DateTime EndTime)
        {

//            #region 用字符串拼接  测试结果,这个正常
//            StringBuilder strSql = new StringBuilder();
//            strSql.Append(@"
//select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
//sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
//from RegInfo ");
//            strSql.Append("where PostTime between '" + BeginTime.ToString() + "' and '" + EndTime .ToString()+ "' ");           
//            return DbHelperSQL.Query(strSql.ToString());
//            #endregion


            #region 用SqlParameter测试  测试结果,这个报超时错误,但放在查询分析器里不报超时
            StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo ");
strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)};
parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
return DbHelperSQL.Query(strSql.ToString(), parameters);

            #endregion

        }

#16


引用 13 楼 jiangshun 的回复:
引用 7 楼 x2670316290 的回复:

引用 5 楼 hualilihua 的回复:

这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?


两个效率没有高低的说法……


我确认过三次,刚才又确认了一次,确实是datetime类型。

#17


引用 14 楼 yanbuodiao 的回复:
引用 12 楼 yanbuodiao 的回复:
C# code


StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney……



我也觉得不应该有这种问题,我上面把代码发出来了,传过来的值,确认是datetime类型的

#18


new SqlParameter("@BeginTime", SqlDbType.DateTime),
你只是指定了传值的类型是 SqlDbType.DateTime 型。
但是没有传值啊。

#19


public SqlParameter(string parameterName, object value)
public SqlParameter(string parameterName, SqlDbType dbType)
这两个方法是根据传值不同有区别的。个人感觉是这个原因。

#20


引用 18 楼 agilesoftstudio 的回复:
new SqlParameter("@BeginTime", SqlDbType.DateTime),
你只是指定了传值的类型是 SqlDbType.DateTime 型。
但是没有传值啊。


我再开个贴子吧,这里可能有的朋友没看到我后面发的代码。

#21


明显就是传参类型和数据库中字段的实际类型不一致导致的

#22


引用 8 楼 x2670316290 的回复:
引用 6 楼 hualilihua 的回复:

唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。


发错啦 不好意思 lz不要有意见呀 

#23


引用 21 楼 xfreyes 的回复:
明显就是传参类型和数据库中字段的实际类型不一致导致的



我确认了已四次了

#24



parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
//这里的BeginTime和EndTime是啥类型的?先强转成DateTime类型的试试  个人猜测的

#25


引用 22 楼 hualilihua 的回复:
引用 8 楼 x2670316290 的回复:
引用 6 楼 hualilihua 的回复:

唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。


发错啦 不好意思 lz不要有意见呀


没事,帮我看看这个东西什么情况引起的。

#26


引用 24 楼 yanbuodiao 的回复:
C# code

parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
//这里的BeginTime和EndTime是啥类型的?先强转成DateTime类型的试试  个人猜测的


传过来的时候,已是DateTime类型

#27



return DbHelperSQL.Query(strSql.ToString(), parameters);
//按照你的意思  应该是这句执行的时候卡住了  建议lz跟进去 断点直接打到真正执行的那句 完后跟一下
//各个变量的值  把Sql语句放到查询分析器中  注意也是用参数查询  看看问题到底在哪了

#28


引用 27 楼 yanbuodiao 的回复:
C# code

return DbHelperSQL.Query(strSql.ToString(), parameters);
//按照你的意思  应该是这句执行的时候卡住了  建议lz跟进去 断点直接打到真正执行的那句 完后跟一下
//各个变量的值  把Sql语句放到查询分析器中  注意也是用参数查询  看看问题到底在哪了


是的,跟进去了的,就是在执行这个语句的时候报超时。

#29


变量的值就那么两个,一个开始时间,一个结束时间

#30



strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



declare @BeginTime DateTime,
……--lz自己补全  直接在查询分析器中试试
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo where PostTime between @BeginTime and @EndTime  group by RegInfo.GameKey order by RegInfo.GameKey 

#31


语句本身是没有问题的,这种肯定是性能上的小细节哪里没有对。
测试了一天才发现是这个参数引起的,很是没有想到

#32


引用 30 楼 yanbuodiao 的回复:
C# code

strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



SQL code

declare @BeginTime DateTime,
……--lz自己补全  直接在查询分析器中试试
select GameKey as [GameKey],max(GameN……



谢谢兄弟,积极回复,跟踪过SQL,在查询分析器里执行很快,跟字符串拼接是一样的效果。

#33


引用 32 楼 x2670316290 的回复:
引用 30 楼 yanbuodiao 的回复:

C# code

strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



SQL code

declare @BeginTime DateTime,
……--lz自己补全 直接在查询分析器中试试
selec……

我去  灵异了?搞不懂了……

#34


个人感觉  程序不骗人  lz在好好跟跟  一句一句的跟   
还有就是 有些问题在这个当口就是找不到原因  晚上回去睡觉的在想想 没准一下就通了  个人经验
或者找别人跟跟  或许有想不到的效果

#35


引用 34 楼 yanbuodiao 的回复:
个人感觉  程序不骗人  lz在好好跟跟  一句一句的跟   
还有就是 有些问题在这个当口就是找不到原因  晚上回去睡觉的在想想 没准一下就通了  个人经验
或者找别人跟跟  或许有想不到的效果



也许吧。

#36


引用 35 楼 x2670316290 的回复:
引用 34 楼 yanbuodiao 的回复:

个人感觉 程序不骗人 lz在好好跟跟 一句一句的跟
还有就是 有些问题在这个当口就是找不到原因 晚上回去睡觉的在想想 没准一下就通了 个人经验
或者找别人跟跟 或许有想不到的效果



也许吧。

找到原因 给贴上来  不相信灵异

#37


我测试了下 没错 (数据就几条)

#38


给你断代码测试下哪个耗的时间多、  


DateTime dt = DateTime.Now;
你的代码....
  DateTime dt2 = DateTime.Now;
  TimeSpan ts = dt2 - dt;
  double Mill = ts.TotalMilliseconds;
  MessageBox.Show(Math.Round(Mill / 1000, 3).ToString()+"毫秒");

#39


SqlParameter确实有效率问题,但是可以防注入。
所以我总是叫别人用SqlParameter,我自己拼字符串,因为我的程序是生成的。
但是SqlParameter引起超时还真不知道

#40


用sql参数的话优化器可能无法知道输入的数据从而造成全表扫描,所以要比前者慢

#41


直接 new SqlParameter("@BeginTime", BeginTime),
  new SqlParameter("@EndTime", EndTime)};
试试,其实不需要写那么咯嗦的写法

#42


SqlParameter 效率 高 不用 考虑
应为 :占用数据 库资源 

采用 sql 每次 数据库都为 认为 是新的语句 
采用 SqlParameter 数据库里产生的 语句 只有一条

检测 数据库,便知道 
第一种 :数据库参生 很多 不同的对象 在 一个 应用中
第二种:数据库参生一个对象 在 一个 应用中

有时查询 几条 比几十条 还 慢 不防 考虑考虑 改成后者

#43


SqlParameter 数据库里产生的 语句 只有一条

只是 参数 不同 语句 在 数据库里 语句只有一个

#44


这是 血的教训 

#45


引用 42 楼 tigerleq 的回复:
SqlParameter 效率 高 不用 考虑
应为 :占用数据 库资源 

采用 sql 每次 数据库都为 认为 是新的语句 
采用 SqlParameter 数据库里产生的 语句 只有一条

检测 数据库,便知道 
第一种 :数据库参生 很多 不同的对象 在 一个 应用中
第二种:数据库参生一个对象 在 一个 应用中

有时查询 几条 比几十条 还 慢 不防 考虑考虑 改……

确实有这么回事,拼sql占用的资源多,但是这个资源有淘汰机制,不是主要问题。

主要的问题是SqlParameter方式的sql语句只需要解析一次,基本相当与存储过程,记得2008才采取sql语句缓存的形式(也许2005也支持,没用过)。
在这种情况下,问题转化为到底解析SqlParameter参数效率高,还是解析sql语句效率高。
经个人测试,SqlParameter解析的效率是很低的,当然sql语句较长而SqlParameter较少的时候也会有反例,我认为这种情况存储过程更合适。几年前,我个人的做法在第一次执行大SQL之前生成存储过程,不过现在不关注这些东西了。

#46


另外一直有一个问题,2008解析SQL比2000慢太多,不知道是什么原因,估计与这个缓存有很大关系,但是不知道怎么禁用它。因为我可以用程序判断应该用SQL语句还是存储过程,是需要缓存还是不需要,被缓存的感觉真不爽。

#47


用sql参数的话优化器可能无法知道输入的数据从而造成全表扫描,所以要比前者慢

#48


strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)}

//这里,我没有看到任何赋值语句,SqlParameter[0],SqlParameter[1]的值是什么?还是默认值?

#49


效率方面不了解,不过好像后者安全性高一些

#50


该回复于2012-02-10 09:46:21被版主删除

#1


1、貌似两句sql不一样,后者缺少group
2、如果一样,查询分析器是一样的,因为只是分析语句,加参不加参,对性能影响不大,除非太多

#2


SqlDbType.DateTime这是日期格式
BeginTime.ToString是字符串形式
你这两个结果一样吗?

#3


引用 1 楼 jiuhexuan 的回复:
1、貌似两句sql不一样,后者缺少group
2、如果一样,查询分析器是一样的,因为只是分析语句,加参不加参,对性能影响不大,除非太多


1."后者缺少 group "是因为我复制上来的时候少复制了一句,两句SQL都加了group by 的。
2.参数查询只加了一个日期,没加其它的了。通过跟踪出来的语句,然后在查询分析器里执行,效率都是一样的,但就是通过c#程序执行的时候,第二种写法报错(超时)。

#4


引用 2 楼 bdmh 的回复:
SqlDbType.DateTime这是日期格式
BeginTime.ToString是字符串形式
你这两个结果一样吗?


 public DataSet GetRegInfoGameList(DateTime BeginTime, DateTime EndTime)
传入参数的类型肯定是一样的。
你所说的两个类型肯定是不一样的,不是都推荐用  SqlParameter  来写吗?
如果可以用字符串拼接的方式来写,我不这么头痛了。


对了,我的环境是 Win7(64位操作系统),VS2010(.net 4.0)+SQL2008

#5


这两个怎么能扯到一块呢

#6


唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”

#7


引用 5 楼 hualilihua 的回复:
这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?

#8


引用 6 楼 hualilihua 的回复:
唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。

#9


估计你数据库里面PostTime字段是不是smalldatetime类型?

#10


引用 6 楼 hualilihua 的回复:
唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”


实在不明白,您这句话,和我这个代码错误有什么关联。

#11


引用 9 楼 jiangshun 的回复:
估计你数据库里面PostTime字段是不是smalldatetime类型?


谢谢,jiangshun 的回复,我开始也以为是和数据库里字段类型不匹配,核对了三次,确实是datetime 
长度为8位的那种,也不是datetime2(7).

#12



StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo ");
strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)}
}
//没有看到参数的值 啥的

lz把代码贴全了瞧瞧

#13


引用 7 楼 x2670316290 的回复:
引用 5 楼 hualilihua 的回复:

这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?


两个效率没有高低的说法,我估计是你数据库里面的字段类型和声明参数的时候字段类型不一样
比如数据库是varchar类型的
在SqlParameter(string parameterName, object value)时候,没有指明具体的类型,所以,默认的就成了nvarchar类型的,在数据量过KW的时候就会出现和varchar类型速度上的区别

#14


引用 12 楼 yanbuodiao 的回复:
C# code


StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.……

或者你在指定值的时候 先把那俩字串 转成DataTime类型的试试 不应该有这种问题的

#15


引用 12 楼 yanbuodiao 的回复:
C# code

StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.Clear……




 public DataSet GetRegInfoGameList(DateTime BeginTime, DateTime EndTime)
        {

//            #region 用字符串拼接  测试结果,这个正常
//            StringBuilder strSql = new StringBuilder();
//            strSql.Append(@"
//select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
//sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
//from RegInfo ");
//            strSql.Append("where PostTime between '" + BeginTime.ToString() + "' and '" + EndTime .ToString()+ "' ");           
//            return DbHelperSQL.Query(strSql.ToString());
//            #endregion


            #region 用SqlParameter测试  测试结果,这个报超时错误,但放在查询分析器里不报超时
            StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo ");
strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)};
parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
return DbHelperSQL.Query(strSql.ToString(), parameters);

            #endregion

        }

#16


引用 13 楼 jiangshun 的回复:
引用 7 楼 x2670316290 的回复:

引用 5 楼 hualilihua 的回复:

这两个怎么能扯到一块呢


这个是因为在项目中,有遇到的,开始是使用的 SqlParameter 来写,但报超时错误,就改成字符串拼接,居然正常了,觉得比较神奇,就上现问一下高手们是怎么回事了,为什么SqlParameter  还不如字符串拼接效率高?


两个效率没有高低的说法……


我确认过三次,刚才又确认了一次,确实是datetime类型。

#17


引用 14 楼 yanbuodiao 的回复:
引用 12 楼 yanbuodiao 的回复:
C# code


StringBuilder strSql = new StringBuilder();
strSql.Append(@"
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney……



我也觉得不应该有这种问题,我上面把代码发出来了,传过来的值,确认是datetime类型的

#18


new SqlParameter("@BeginTime", SqlDbType.DateTime),
你只是指定了传值的类型是 SqlDbType.DateTime 型。
但是没有传值啊。

#19


public SqlParameter(string parameterName, object value)
public SqlParameter(string parameterName, SqlDbType dbType)
这两个方法是根据传值不同有区别的。个人感觉是这个原因。

#20


引用 18 楼 agilesoftstudio 的回复:
new SqlParameter("@BeginTime", SqlDbType.DateTime),
你只是指定了传值的类型是 SqlDbType.DateTime 型。
但是没有传值啊。


我再开个贴子吧,这里可能有的朋友没看到我后面发的代码。

#21


明显就是传参类型和数据库中字段的实际类型不一致导致的

#22


引用 8 楼 x2670316290 的回复:
引用 6 楼 hualilihua 的回复:

唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。


发错啦 不好意思 lz不要有意见呀 

#23


引用 21 楼 xfreyes 的回复:
明显就是传参类型和数据库中字段的实际类型不一致导致的



我确认了已四次了

#24



parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
//这里的BeginTime和EndTime是啥类型的?先强转成DateTime类型的试试  个人猜测的

#25


引用 22 楼 hualilihua 的回复:
引用 8 楼 x2670316290 的回复:
引用 6 楼 hualilihua 的回复:

唉!我终于有点明白了,交流会上老大说过的话:“中国硬编码的人太多了”



不明白兄弟,您的意思,请明示。


发错啦 不好意思 lz不要有意见呀


没事,帮我看看这个东西什么情况引起的。

#26


引用 24 楼 yanbuodiao 的回复:
C# code

parameters[0].Value = BeginTime;
parameters[1].Value = EndTime;
//这里的BeginTime和EndTime是啥类型的?先强转成DateTime类型的试试  个人猜测的


传过来的时候,已是DateTime类型

#27



return DbHelperSQL.Query(strSql.ToString(), parameters);
//按照你的意思  应该是这句执行的时候卡住了  建议lz跟进去 断点直接打到真正执行的那句 完后跟一下
//各个变量的值  把Sql语句放到查询分析器中  注意也是用参数查询  看看问题到底在哪了

#28


引用 27 楼 yanbuodiao 的回复:
C# code

return DbHelperSQL.Query(strSql.ToString(), parameters);
//按照你的意思  应该是这句执行的时候卡住了  建议lz跟进去 断点直接打到真正执行的那句 完后跟一下
//各个变量的值  把Sql语句放到查询分析器中  注意也是用参数查询  看看问题到底在哪了


是的,跟进去了的,就是在执行这个语句的时候报超时。

#29


变量的值就那么两个,一个开始时间,一个结束时间

#30



strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



declare @BeginTime DateTime,
……--lz自己补全  直接在查询分析器中试试
select GameKey as [GameKey],max(GameName) as [GameName],COUNT(1) as [TCount],
sum(RegInfo.OkMoney) as [TMoney],sum(RegInfo.ClearingMoney) as [ClearingMoney],sum(RegInfo.ReturnMoney) as [ReturnMoney]
from RegInfo where PostTime between @BeginTime and @EndTime  group by RegInfo.GameKey order by RegInfo.GameKey 

#31


语句本身是没有问题的,这种肯定是性能上的小细节哪里没有对。
测试了一天才发现是这个参数引起的,很是没有想到

#32


引用 30 楼 yanbuodiao 的回复:
C# code

strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



SQL code

declare @BeginTime DateTime,
……--lz自己补全  直接在查询分析器中试试
select GameKey as [GameKey],max(GameN……



谢谢兄弟,积极回复,跟踪过SQL,在查询分析器里执行很快,跟字符串拼接是一样的效果。

#33


引用 32 楼 x2670316290 的回复:
引用 30 楼 yanbuodiao 的回复:

C# code

strSql.Append(@" group by RegInfo.GameKey order by RegInfo.GameKey ");
//这句在传参数的没有



SQL code

declare @BeginTime DateTime,
……--lz自己补全 直接在查询分析器中试试
selec……

我去  灵异了?搞不懂了……

#34


个人感觉  程序不骗人  lz在好好跟跟  一句一句的跟   
还有就是 有些问题在这个当口就是找不到原因  晚上回去睡觉的在想想 没准一下就通了  个人经验
或者找别人跟跟  或许有想不到的效果

#35


引用 34 楼 yanbuodiao 的回复:
个人感觉  程序不骗人  lz在好好跟跟  一句一句的跟   
还有就是 有些问题在这个当口就是找不到原因  晚上回去睡觉的在想想 没准一下就通了  个人经验
或者找别人跟跟  或许有想不到的效果



也许吧。

#36


引用 35 楼 x2670316290 的回复:
引用 34 楼 yanbuodiao 的回复:

个人感觉 程序不骗人 lz在好好跟跟 一句一句的跟
还有就是 有些问题在这个当口就是找不到原因 晚上回去睡觉的在想想 没准一下就通了 个人经验
或者找别人跟跟 或许有想不到的效果



也许吧。

找到原因 给贴上来  不相信灵异

#37


我测试了下 没错 (数据就几条)

#38


给你断代码测试下哪个耗的时间多、  


DateTime dt = DateTime.Now;
你的代码....
  DateTime dt2 = DateTime.Now;
  TimeSpan ts = dt2 - dt;
  double Mill = ts.TotalMilliseconds;
  MessageBox.Show(Math.Round(Mill / 1000, 3).ToString()+"毫秒");

#39


SqlParameter确实有效率问题,但是可以防注入。
所以我总是叫别人用SqlParameter,我自己拼字符串,因为我的程序是生成的。
但是SqlParameter引起超时还真不知道

#40


用sql参数的话优化器可能无法知道输入的数据从而造成全表扫描,所以要比前者慢

#41


直接 new SqlParameter("@BeginTime", BeginTime),
  new SqlParameter("@EndTime", EndTime)};
试试,其实不需要写那么咯嗦的写法

#42


SqlParameter 效率 高 不用 考虑
应为 :占用数据 库资源 

采用 sql 每次 数据库都为 认为 是新的语句 
采用 SqlParameter 数据库里产生的 语句 只有一条

检测 数据库,便知道 
第一种 :数据库参生 很多 不同的对象 在 一个 应用中
第二种:数据库参生一个对象 在 一个 应用中

有时查询 几条 比几十条 还 慢 不防 考虑考虑 改成后者

#43


SqlParameter 数据库里产生的 语句 只有一条

只是 参数 不同 语句 在 数据库里 语句只有一个

#44


这是 血的教训 

#45


引用 42 楼 tigerleq 的回复:
SqlParameter 效率 高 不用 考虑
应为 :占用数据 库资源 

采用 sql 每次 数据库都为 认为 是新的语句 
采用 SqlParameter 数据库里产生的 语句 只有一条

检测 数据库,便知道 
第一种 :数据库参生 很多 不同的对象 在 一个 应用中
第二种:数据库参生一个对象 在 一个 应用中

有时查询 几条 比几十条 还 慢 不防 考虑考虑 改……

确实有这么回事,拼sql占用的资源多,但是这个资源有淘汰机制,不是主要问题。

主要的问题是SqlParameter方式的sql语句只需要解析一次,基本相当与存储过程,记得2008才采取sql语句缓存的形式(也许2005也支持,没用过)。
在这种情况下,问题转化为到底解析SqlParameter参数效率高,还是解析sql语句效率高。
经个人测试,SqlParameter解析的效率是很低的,当然sql语句较长而SqlParameter较少的时候也会有反例,我认为这种情况存储过程更合适。几年前,我个人的做法在第一次执行大SQL之前生成存储过程,不过现在不关注这些东西了。

#46


另外一直有一个问题,2008解析SQL比2000慢太多,不知道是什么原因,估计与这个缓存有很大关系,但是不知道怎么禁用它。因为我可以用程序判断应该用SQL语句还是存储过程,是需要缓存还是不需要,被缓存的感觉真不爽。

#47


用sql参数的话优化器可能无法知道输入的数据从而造成全表扫描,所以要比前者慢

#48


strSql.Append("where PostTime between @BeginTime and @EndTime ");
SqlParameter[] parameters = {
  new SqlParameter("@BeginTime", SqlDbType.DateTime),
  new SqlParameter("@EndTime", SqlDbType.DateTime)}

//这里,我没有看到任何赋值语句,SqlParameter[0],SqlParameter[1]的值是什么?还是默认值?

#49


效率方面不了解,不过好像后者安全性高一些

#50


该回复于2012-02-10 09:46:21被版主删除