首頁猿問在連接關(guān)閉之前查詢完成后實(shí)體框架掛起

在連接關(guān)閉之前查詢完成后實(shí)體框架掛起

C#

絕地?zé)o雙 2022-01-09 10:31:30

我正在嘗試提高相對復(fù)雜的實(shí)體框架查詢的性能。使用DbContext.Database.Log我在執(zhí)行我感興趣的主要查詢時檢查輸出的操作，我發(fā)現(xiàn)了一些奇怪的東西。根據(jù)日志，查詢本身只需要大約 10,000 毫秒，但是在查詢“完成”和連接關(guān)閉之間有超過一分鐘的時間。我不知道這次發(fā)生了什么，因?yàn)槿罩撅@示一個空白行。這是輸出：2018-09-07 14:10:34,641 [1] INFO EntityDataRepository [jobInstanceID: 0] - -- 執(zhí)行于 2018 年 9 月 7 日下午 2:10:34 -07:002018-09-07 14:10:46,421 [1] INFO EntityDataRepository [jobInstanceID: 0] - -- 在 11776 毫秒內(nèi)完成，結(jié)果：SqlDataReader2018-09-07 14:10:46,458 [1] INFO EntityDataRepository [jobInstanceID: 0] -2018-09-07 14:11:48,667 [1] INFO EntityDataRepository [jobInstanceID: 0] - 2018 年 9 月 7 日下午 2:11:48 -07:00 關(guān)閉連接有人可以告訴我這里發(fā)生了什么嗎？請參閱下面的代碼的簡化/通用版本：(from child in entities.SelectMany(e => e.children.Where(childFilter))join read in childReads on child.ID equals read.childIDjoin readType in readTypes on read.readTypeID equals readType.IDwhere readFilterselect new {child, read, readType}).ToList()

查看完整描述

1 回答

catspeake

TA貢獻(xiàn)1111條經(jīng)驗(yàn) 獲得超0個贊

2018-09-07 14:10:46,421 1 INFO EntityDataRepository [jobInstanceID: 0] - -- 在 11776 毫秒內(nèi)完成，結(jié)果：SqlDataReader

這意味著SqlCommand.ExecuteReader()已經(jīng)完成，服務(wù)器開始向客戶端返回行。SQL Sever 中的查詢此時仍在執(zhí)行。它可能已經(jīng)假脫機(jī)了所有查詢結(jié)果，或者它可能剛剛使用流式查詢計(jì)劃找到并返回了前幾個匹配的行。因此，IQueryable<T>.ToList()要完成，查詢需要在服務(wù)器上完成執(zhí)行，結(jié)果行必須傳輸?shù)娇蛻舳?，EF 必須讀取行并將它們具體化為 type 的類實(shí)例T。

可以使用Visual Studio Profiler、性能計(jì)數(shù)器或System.Diagnostics.Process分析客戶端工作。

SQL Server 跟蹤計(jì)劃緩存中查詢的查詢執(zhí)行統(tǒng)計(jì)信息，如果在 SQL 2016+ 中使用查詢存儲，則跟蹤所有查詢。統(tǒng)計(jì)信息將向您顯示查詢經(jīng)過的時間，其中包括等待客戶端讀?。ê吞幚恚┬泻退衅渌却臅r間，以及“工作時間”，即查詢使用的 CPU 時間。SQL 2017 和 Azure SQL 數(shù)據(jù)庫中的查詢存儲還跟蹤每個查詢的等待統(tǒng)計(jì)信息，因此您可以區(qū)分客戶端ASYNC_NETWORK_IO等待( ) 和其他等待，如數(shù)據(jù)文件讀取 ( PAGEIOLATCH)、鎖定等待 ( LCK_*_*) 等。