La requête Entity Framework Core 3.0 provoque «SqlException: 'Execution Timeout Expired'» et tempdb devient saturé. Fonctionne avec EF Core 2.2.6

Il s'agit d'un changement de rupture documenté dans EF Core 3: le chargement hâtif des entités associées se produit désormais dans une seule requête

Le nouveau comportement est similaire à la génération de requêtes dans EF6, où plusieurs inclusions peuvent créer des requêtes très volumineuses et coûteuses. Ces requêtes peuvent également échouer en raison de délais d'expiration, des coûts de génération du plan de requête ou de l'épuisement des ressources d'exécution des requêtes.

Ainsi, tout comme dans EF6, vous devez vous abstenir d'inclure plusieurs chemins d'inclusion d'entités non liés, car ils créent des requêtes très coûteuses.

Au lieu de cela, vous pouvez utiliser le chargement différé, ou charger explicitement des parties du graphique d'entité dans des requêtes distinctes et laisser le suivi des modifications corriger les propriétés de navigation.

EF 5 a ajouté une option pour désactiver la génération d'une seule grande requête appelée Split Queries .

Ajout à la réponse @ DavidBrowne-Microsoft.

Supposons que nous ayons les entités et les navigations suivantes dans le modèle

// Customer Include Address
SELECT [c].[Id], [c].[CustomerName], [a].[Id], [a].[City], [a].[CustomerId]
FROM [Customers] AS [c]
LEFT JOIN [Address] AS [a] ON [c].[Id] = [a].[CustomerId]
WHERE ([c].[CustomerName] = N'John') AND [c].[CustomerName] IS NOT NULL

// Order Include Order discount
SELECT [o].[Id], [o].[CustomerId], [o].[OrderDate], [o0].[Id], [o0].[Discount], [o0].[OrderId]
FROM [Customers] AS [c]
INNER JOIN [Order] AS [o] ON [c].[Id] = [o].[CustomerId]
LEFT JOIN [OrderDiscount] AS [o0] ON [o].[Id] = [o0].[OrderId]
WHERE ([c].[CustomerName] = N'John') AND [c].[CustomerName] IS NOT NULL

// OrderDetails
SELECT [o0].[Id], [o0].[OrderId], [o0].[ProductName]
FROM [Customers] AS [c]
INNER JOIN [Order] AS [o] ON [c].[Id] = [o].[CustomerId]
INNER JOIN [OrderDetail] AS [o0] ON [o].[Id] = [o0].[OrderId]
WHERE ([c].[CustomerName] = N'John') AND [c].[CustomerName] IS NOT NULL

Vous devrez réécrire uniquement pour les navigations de collection, les navigations de référence peuvent faire partie de la même requête.

var baseQuery = db.Customers.Include(c => c.Address).Where(c => c.CustomerName == "John");
var result = baseQuery.ToList(); // Or async method, If doing FirstOrDefault, add Take(1) to base query
baseQuery.Include(c => c.Orders).ThenInclude(o => o.OrderDiscount).SelectMany(c => c.Orders).Load();
baseQuery.SelectMany(c => c.Orders).SelectMany(o => o.OrderDetails).Load();

Cela générera 3 requêtes sur le serveur. Ce serait un SQL légèrement plus optimisé que ce que EF Core 2.2 a généré. Et StateManager réparera les navigations. Cela évite également de dupliquer les enregistrements provenant du serveur vers le client.

SQL généré:

Customer
Customer.Address (reference nav)
Customer.Orders (collection nav)
Order.OrderDetails (collection nav)
Order.OrderDiscount (reference nav)

Edit: Si vous n'avez pas de navigation CLR à utiliser dans SelectMany, vous pouvez utiliser EF.Property pour référencer la navigation de collection.

Source: https://github.com/aspnet/EntityFrameworkCore/issues/18022#issuecomment-537219137

Vous devez changer votre code comme celui-ci, cela générera plus de requêtes et évitera le temps mort

db.Profiles.AsTracking().Where(........

rappelez-vous que la requête doit être exécutée en mode Tracking. s'il ne charge pas les fils, vous pouvez ajouter asTracking comme ceci:

var dbProfile = db.Profiles.SingleOrDefault(x => x.SiteId == Int32.Parse(id));
dbProfile.Include(x => x.Interests).Load();
dbProfile.Include(x => x.Pets).Load();
dbProfile.Include(x => x.Networks).Load();
dbProfile.Include(x => x.PersonalityTraits).Load();