SQL-query 在代码中比直接查询 db 花费更长的时间
Posted
技术标签:
【中文标题】SQL-query 在代码中比直接查询 db 花费更长的时间【英文标题】:SQL-query takes a lot longer time in code than query db direct 【发布时间】:2011-09-15 07:49:23 【问题描述】:我有一个 SQL 查询,当我使用 SQL Management Studio 时执行不到一秒,但是当我的代码执行它时,从数据库服务器获取结果需要 30 多秒。结果包含 1700 行。另一个类似的查询返回 900 行,执行需要几毫秒。这种奇怪行为的原因是什么?
public SqlDataReader ExecuteReader(string strSQL, ArrayList arParams)
OpenConnection();
SqlCommand myCommand = new SqlCommand(strSQL, myConnection);
myCommand.CommandTimeout = intTimeout;
foreach (SqlParameter myParameter in arParams)
myCommand.Parameters.Add(myParameter);
return myCommand.ExecuteReader(System.Data.CommandBehavior.CloseConnection);
strSQL:
SELECT [Group].[Id]
,[Group].[intCustomerId]
,[Group].[strName]
,[Permission].[dtmCreated]
,[Permission].[intPermissionTypeId]
,[Permission].[intObjectTypeId]
,[Permission].[intObjectId]
,[Permission].[blnActive]
,[Permission].[blnHaveAccess]
,[Permission].[intLevelTypeId]
FROM [Group]
LEFT JOIN Permission ON [Group].[Id] = intGroupId AND
intObjectId = @ObjectId AND
intObjectTypeId = @ObjectTypeId AND
intLevelTypeId = @LevelType AND
intPermissionTypeId = @PermissionTypeId AND
blnActive = 1
WHERE [Group].[intCustomerId] = @CustomerId AND
[Group].[blnDeleted] = 0
ORDER BY strName, blnActive DESC
arParams:
arParams.Add(DatabaseHandler.MakeSqlParameter("@CustomerId", customer.Id));
arParams.Add(DatabaseHandler.MakeSqlParameter("@ObjectId", masterprocess.Id));
arParams.Add(DatabaseHandler.MakeSqlParameter("@ObjectTypeId", Convert.ToInt32(ObjectType.MasterProcess)));
arParams.Add(DatabaseHandler.MakeSqlParameter("@PermissionTypeId", Convert.ToInt32(permissiontype)));
arParams.Add(DatabaseHandler.MakeSqlParameter("@LevelType", Convert.ToInt32(leveltype)));
DatabaseHandler.MakeSqlParameter:
public static SqlParameter MakeSqlParameter(String strName, int intInput)
return new SqlParameter(strName, intInput);
【问题讨论】:
看看***.com/questions/1642453/… 和@gbn 的回答。我想,可能是 SQLParameters 的数据类型与 SQL 所期望的不同步。例如一个或多个 SQLParameter 的参数类型可以是 varchar 而它应该是一个 int(正如 SQL 所期望的那样)。 这可能是“参数嗅探”的情况,但是要适用:strSQL
是文字查询还是内部调用查询的某些存储过程的名称?您是否在两种情况下都使用相同的参数值进行测试?
如果那个盒子有足够的内存,也许可以发帖? SQL 管理工具对当前的 Rescource 等待有何看法?
@Christian.K strSQL 是文字查询。我用相同的参数做测试
@EKS:资源等待说 0,但是当我从代码运行查询时,处理器时间达到 100%
【参考方案1】:
根据您对 cmets 的回复,我认为正确的解决方案是索引。
最简单的方法是在运行正常查询时运行 sql 日志记录,然后运行 sql profiler。
根据它的建议,它可能会发现缺失的索引。
【讨论】:
你似乎把我推向了正确的方向。我发现我可以重建索引,就像我在我的权限表上所做的那样,现在它以正常速度运行。仍然不明白为什么在管理工作室中运行查询比在代码中运行要快得多。【参考方案2】:我遇到了同样的问题,但是在看这个问题时想到了解决方案。
当您使用带参数的 SQLCommand 运行查询时,查询的执行方式不同。它使用存储过程助手来打包参数。类似 Exec sp_Execute。
如果您进行参数替换,您应该会注意到改进(我知道那时存在 SQL 注入的风险)。
您还可以更进一步,在表旁边指定 WITH(INDEX) 以指定要使用的索引。 (因为它可能会尝试使用 PK 索引)。
【讨论】:
以上是关于SQL-query 在代码中比直接查询 db 花费更长的时间的主要内容,如果未能解决你的问题,请参考以下文章