與SSMS相比，EntityFramework的查詢時間極其緩慢

我繼承了一個代碼庫，我在使用 Entity Framework Core v3.1.19 時遇到一個奇怪的問題。

Entity Framework 正在生成以下查詢（如在 SQL Server Profiler 中發現的那樣），并且運行時間接近 30 秒，而在 SSMS 中運行相同的代碼（同樣取自 profiler）需要 1 秒（這是一個例子，但整個網站在從資料庫獲取資料時運行速度極慢）。

exec sp_executesql N'SELECT [t].[Id], [t].[AccrualLink], [t].[BidId], [t].[BidId1], [t].[Cancelled], [t].[ClientId], [t].[CredatedUtc], [t]. [CreatorUserId], [t].[Date], [t].[DeletedUtc], [t].[DeleterUserId], [t].[EmergencyContact], [t].[EmergencyName], [t]. [EmergencyPhone], [t].[EndDate], [t].[FinalizerId], [t].[Guid], [t].[Invoiced], [t].[IsDeleted], [t].[Notes], [t].[OfficeId], [t] . [PONumber], [t].[PlannerId], [t].[PortAgencyAgentEmail], [t].[PortAgencyAgentName], [t].[PortAgencyAgentPhone], [t]. [PortAgencyId], [t].[PortAgentId], [t].[PortId], [t].[PortType], [t].[PositionNote], [t].[ProposalLink], [t].[ServiceId], [t] . [ShipId], [t].[ShorexAssistantEmail], [t].[ShorexAssistantName], [t].[ShorexAssistantPhone], [t].[ShorexManagerEmail], [t]. [ShuttleBusPhone], [t].[ShuttleBusServiceProvided], [t].[TouristInformationBus], [t].[TouristInformationEmail], [t].[TouristInformationName], [t].[TouristInformationPhone], [t].[TouristInformationServiceProvided], [t]. [UpdateUtc], [t]. [UpdaterUserId], [t].[Water], [t].[WaterDetails], [t0].[Id], [t0].[CreatedUtc], [t0].[CreatorUserId], [t0].[DeletedUtc], [t0]. [DeleterUserId], [t0].[Guid], [t0].[IsDeleted], [t0].[LanguageId], [t0].[Logo], [t0].[Name], [t0].[Note], [t0].[OldId], [t0]. [PaymentTerms], [t0].[Pricing], [t0].[Services], [t0].[Status], [t0].[UpdateUtc], [t0].[UpdaterUserId], [t1].[Id], [t1]. [CreatedUtc], [t1].[CreatorUserId], [t1].[DeletedUtc], [t1].[DeleterUserId], [t1].[Guid], [t1].[IsDeleted], [t1]. [Name], [t1].[OldId], [t1].[UpdatedUtc], [t1].[UpdaterUserId], [s].[Id], [s].[CreatedUtc], [s].[CreatorUserId], [s]. [DeletedUtc], [s].[DeleterUserId], [s].[Guid], [s].[IsDeleted], [s].[Name], [s].[Pax], [s].[UpdatedUtc], [s].[UpdaterUserId]/span>
FROM (
    SELECT [o].[Id], [o].[AccrualLink], [o].[BidId], [o].[BidId1], [o].[Cancelled], [o].[ClientId], [o].[CreatedUtc], [o]. [CreatorUserId], [o].[Date], [o].[DeletedUtc], [o].[DeleterUserId], [o].[EmergencyContact], [o].[EmergencyName], [o]. [EmergencyPhone], [o].[EndDate], [o].[FinalizerId], [o].[Guid], [o].[Invoiced], [o].[IsDeleted], [o].[Notes], [o].[OfficeId], [o].[PONumber], [o]. [PlannerId], [o].[PortAgencyAgentEmail], [o].[PortAgencyAgentName], [o].[PortAgencyAgentPhone], [o].[PortAgencyId], [o]. [PortType], [o].[PositionNote], [o].[ProposalLink], [o].[ServiceId], [o].[ShipId], [o].[ShorexAssistantEmail], [o].[ShorexAssistantName], [o]. [ShorexAssistantPhone], [o].[ShorexManagerEmail], [o].[ShorexManagerName], [o].[ShorexManagerPhone], [o].[ShuttleBus], [o].[ShuttleBusEmail], [o]. [ShuttleBusName], [o].[ShuttleBusPhone], [o].[ShuttleBusServiceProvided], [o].[TouristInformationBus], [o].[TouristInformationEmail], [o]. [TouristInformationName], [o].[TouristInformationPhone], [o].[TouristInformationServiceProvided], [o].[UpdateUtc], [o].[UpdaterUserId], [o].[Water], [o].[WaterDetails]
    FROM [OpsDocuments] AS [o)
    WHERE ([o].[IsDeleted] <> CAST(1 AS bit) AND ((CASE)
        WHEN [o]. [Cancelled] = CAST(0 AS bit) THEN CAST(1 AS bit)
        ELSE CAST(0 AS bit)
    END & CASE
        WHEN [o]. [Invoiced] = CAST(0 AS bit) THEN CAST（1 AS bit)
        ELSE CAST(0 AS bit)
    END) = CAST(1 AS bit>)
    ORDER BY [o].[Date]
    OFFSET @__p_0 ROWS FETCH NEXT @__p_1 ROWS ONLY
) AS [t] 。
LEFT JOIN [TourClients] AS [t0] ON [t].[ClientId] = [t0].[Id]
LEFT JOIN [TourLanguages] AS [t1] ON [t0].[LanguageId] = [t1].[Id] 。
LEFT JOIN [Ships] AS [s] ON [t].[ShipId] = [s].[Id]
ORDER BY [t].[Date]',N'@__p_0 int,@__p_1 int',@__p_0=0,@__p_1=10。

這個查詢從可能的55條記錄中回傳10條記錄，所以我們沒有談論大的數字或任何東西。

起初我認為這可能是轉換時的資料型別問題，但檢查了所有的資料型別，它們都是正確的，并且由于該問題顯示在分析器中，我假設這是一個SQL問題，而不是特別是Entity Framework。然而，當我在剖析器中運行時，我找不到兩者之間的任何區別，只是EF的那一個需要30倍的時間。

希望有人能給我一個建議，告訴我應該在哪里找。

編輯：感謝評論中的所有建議。至于Linq和可重復的例子，這將是很棘手的，因為這個專案的代碼基礎是一些奇怪的自制的自動生成系統。你給它一個帶有大量自定義屬性的ViewModel，它試圖為你做一切事情（如此多的抽象層），所以很難找到任何東西。 聽起來，我必須開始把這些東西重寫成更有限的控制器。

uj5u.com熱心網友回復：

EF總是比原始SQL花費更多的時間，因為EF必須為查詢中回傳的每個物體實作跟蹤的物體。

從SQL來看，這是一個跨越4個表的急迫加載查詢，即OPSDocuments、TourClients、TourLanguages和Ships。

在一些看似不相關的變化之后，這可能會突然花費更多的時間：新的關系被偷懶加載。 這方面的一個例子是，該資料正在被序列化，并且一個新的關系已經被添加到一個或多個物體中，而這些物體現在正被懶惰加載命中。(通常情況下，在頁面加載之前，看到額外的查詢會出現，這就是證明。

其他導致這個問題的時間比它應該的要長的原因：

var results = context.OpsDocuments
    .Include(x => x.TourClient)
    .ThenInclude(x => x.TourLanguage)
    .Include(x => x.Ship)
    .OrderBy(x => x.Date)
    .ToList（）。

var results = context.OpsDocuments
    .Select(x => new TourSummaryViewModel)
    {
        DocumentId = x.DocumentId,
        ClientId = x.Client.Id。
        ClientName = x.Client.Name。
        Language = x.Client.Language.Name。
        ShipName = x.Ship.Name。
        Date = x.Date.
    }).OrderBy(x => x.Date)
    .ToList（）。