Dapper.net出現奇怪的超時問題

dapper database-performance sql

我剛才開始使用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事件探查器複製粘貼的查詢。我在我的代碼中執行它。

            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執行的相同查詢。

在此處輸入圖像描述

我還可以補充說,這只是(我認為)當我有兩個或更多的單詞或我在搜索字符串中有一個“停止”字符時發生。所以它可能與全文搜索有關,但我無法弄清楚如何調試它,因為它完美地從Management Studio。

更糟糕的是,它在我的localhost上工作正常,幾乎相同的數據庫來自代碼和Management Studio。

一般承認的答案

Dapper只不過是ado.net上的實用程序包裝器;它不會改變ado.net的運作方式。聽起來我這裡的問題是“在ssms中工作,在ado.net中失敗”。這不是唯一的:偶爾發現這種情況很常見。可能的候選人:

  • “set”選項:這些在ado.net中有不同的默認值 - 並且可能會影響性能,尤其是如果你有計算+持久+索引列這樣的東西 - 如果“set”選項不兼容它可以決定它不能使用存儲的值,因此不是索引 - 而是表掃描和重新計算。還有其他類似的情況。
  • 系統加載/事務隔離級別/阻塞;在ssms中運行某些東西並不會在那個時刻重現整個系統負載
  • 緩存的查詢計劃:有時一個duff計劃被緩存和使用;從ssms運行通常會強制執行一個新計劃 - 這自然會根據您在測試中使用的參數進行調整。更新所有索引統計信息等,並考慮添加“optimize for”查詢提示

熱門答案

在ADO中,ManagementTime infinity中CommandTimeout 30秒的默認值。調整命令超時以調用Query <>,見下文。

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();
}

另請參閱MSDN上的SqlCommand.CommandTimeout屬性



許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow
許可下: CC-BY-SA with attribution
不隸屬於 Stack Overflow