gpt4 book ai didi

sql - Dapper.net 的奇怪超时问题

转载 作者:行者123 更新时间:2023-12-04 00:47:30 25 4
gpt4 key购买 nike

出于性能原因,我不久前开始使用 dapper.net,并且与仅在 LINQ To SQL 中运行“ExecuteQuery”相比,我真的很喜欢命名参数功能。

它适用于大多数查询,但我不时遇到一些非常奇怪的超时。最奇怪的是,这种超时仅在通过 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 Profiler 复制粘贴的查询。我在我的代码中像这样执行它。
            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 执行的查询相同。

enter image description here

我还可以补充说,这仅(我认为)发生在我有两个或更多单词或搜索字符串中有“停止”字符时。所以它可能与全文搜索有关,但我不知道如何调试它,因为它在 Management Studio 中完美运行。

更糟糕的是,它在我的本地主机上运行良好,使用代码和 Management Studio 的几乎相同的数据库。

最佳答案

Dapper 只不过是 ado.net 上的实用程序包装器;它不会改变 ado.net 的运作方式。在我看来,这里的问题是“在 ssms 中有效,在 ado.net 中失败”。这不是唯一的:偶尔会发现这种情况很常见。可能的候选人:

  • “设置”选项:这些在 ado.net 中有不同的默认值 - 并且会影响性​​能,尤其是如果您有计算+持久化+索引列之类的东西 - 如果“设置”选项不兼容,它可以决定它不能使用存储值,因此不是索引 - 而是表扫描和重新计算。还有其他类似的场景。
  • 系统负载/事务隔离级别/阻塞;在 ssms 中运行某些内容不会及时重现整个系统负载
  • 缓存查询计划:有时会缓存和使用 duff 计划;从 ssms 运行通常会强制执行一个新计划 - 自然会针对您在测试中使用的参数进行调整。更新所有索引统计信息等,并考虑添加“优化”查询提示
  • 关于sql - Dapper.net 的奇怪超时问题,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/15683197/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com