我之前因为性能原因开始使用dapper.net而且我真的很喜欢命名参数功能,而不仅仅是运行" ExecuteQuery"在LINQ To SQL中。
它适用于大多数查询,但我不时会得到一些非常奇怪的超时。最奇怪的是,只有在通过dapper执行SQL时才会发生此超时。如果我从分析器中复制执行的查询并在Management Studio中运行它的速度很快并且工作正常。而且它不仅仅是一个临时问题。查询始终通过dapper超时,并在Management Studio中始终正常工作。
exec sp_executesql N'SELECT Item.Name,dbo.PlatformTextAndUrlName(Item.ItemId) As PlatformString,dbo.MetaString(Item.ItemId) As MetaTagString, Item.StartPageRank,Item.ItemRecentViewCount
NAME_SRCH.RANK as NameRank,
DESC_SRCH.RANK As DescRank,
ALIAS_SRCH.RANK as AliasRank,
Item.itemrecentviewcount,
(COALESCE(ALIAS_SRCH.RANK, 0)) + (COALESCE(NAME_SRCH.RANK, 0)) + (COALESCE(DESC_SRCH.RANK, 0) / 20) + Item.itemrecentviewcount / 4 + ((CASE WHEN altrank > 60 THEN 60 ELSE altrank END) * 4) As SuperRank
FROM dbo.Item
INNER JOIN dbo.License on Item.LicenseId = License.LicenseId
LEFT JOIN dbo.Icon on Item.ItemId = Icon.ItemId
LEFT OUTER JOIN FREETEXTTABLE(dbo.Item, name, @SearchString) NAME_SRCH ON
Item.ItemId = NAME_SRCH.[KEY]
LEFT OUTER JOIN FREETEXTTABLE(dbo.Item, namealiases, @SearchString) ALIAS_SRCH ON
Item.ItemId = ALIAS_SRCH.[KEY]
INNER JOIN FREETEXTTABLE(dbo.Item, *, @SearchString) DESC_SRCH ON
Item.ItemId = DESC_SRCH.[KEY]
ORDER BY SuperRank DESC OFFSET @Skip ROWS FETCH NEXT @Count ROWS ONLY',N'@Count int,@SearchString nvarchar(4000),@Skip int',@Count=12,@SearchString=N'box,com',@Skip=0
这是我从SQL事件探查器复制粘贴的查询。我在我的代码中执行它。
using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["Conn"].ToString())) {
connection.Open();
var items = connection.Query<MainItemForList>(query, new { SearchString = searchString, PlatformId = platformId, _LicenseFilter = licenseFilter, Skip = skip, Count = count }, buffered: false);
return items.ToList();
}
我不知道从哪里开始。我认为必须有一些与dapper一起发生的事情,因为当我执行代码时它工作正常。
正如您在此屏幕截图中看到的那样。这是先通过代码然后通过Management Studio执行的相同查询。
我还可以补充说,这只是(我认为)当我有两个或更多的单词或者我有一个&#34;停止&#34;搜索字符串中的char。所以它可能与全文搜索有关,但我无法弄清楚如何调试它,因为它可以从Management Studio中完美运行。
更糟糕的是,它在我的localhost上工作正常,代码和Management Studio都有几乎相同的数据库。
答案 0 :(得分:8)
Dapper只不过是ado.net上的实用程序包装器;它不会改变ado.net的运作方式。听起来我这里的问题是“在ssms中工作,在ado.net中失败”。这不是唯一的:偶尔发现这种情况很常见。可能的候选人:
答案 1 :(得分:7)
在ADO中,CommandTimeout 30秒内的默认值为Management Studio infinity。调整命令超时以调用Query&lt;&gt;,见下文。
var param = new { SearchString = searchString, PlatformId = platformId, _LicenseFilter = licenseFilter, Skip = skip, Count = count };
var queryTimeoutInSeconds = 120;
using (var connection = new SqlConnection(ConfigurationManager.ConnectionStrings["Conn"].ToString()))
{
connection.Open();
var items = connection.Query<MainItemForList>(query, param, commandTimeout: queryTimeoutInSeconds, buffered: false);
return items.ToList();
}
答案 2 :(得分:2)
对于Dapper,默认超时为30秒,但是我们可以通过这种方式增加超时时间。在这里,我们将超时时间增加了240秒(4分钟)。
public DataTable GetReport(bool isDepot, string fetchById)
{
int? queryTimeoutInSeconds = 240;
using (IDbConnection _connection = DapperConnection)
{
var parameters = new DynamicParameters();
parameters.Add("@IsDepot", isDepot);
parameters.Add("@FetchById", fetchById);
var res = this.ExecuteSP<dynamic>(SPNames.SSP_GetSEPReport, parameters, queryTimeoutInSeconds);
return ToDataTable(res);
}
}
在存储库层中,我们可以使用附加参数“ queryTimeoutInSeconds”为存储过程调用自定义ExecuteSP方法。
以下是dapper的“ ExecuteSP”方法:-
public virtual IEnumerable<TEntity> ExecuteSP<TEntity>(string spName, object parameters = null, int? parameterForTimeout = null)
{
using (IDbConnection _connection = DapperConnection)
{
_connection.Open();
return _connection.Query<TEntity>(spName, parameters, commandTimeout: parameterForTimeout, commandType: CommandType.StoredProcedure);
}
}
答案 3 :(得分:1)
可能是在Dapper中设置命令超时的问题。以下是如何在Dapper中调整命令超时的示例: Setting Command Timeout in Dapper