En finir une fois pour toutes avec le problème des requêtes N+1

Par Mirko Peters · 2026-08-12

Traduit automatiquement par IA à partir de l'article original. Lire l'original en anglais

Titelbild: Conquering the N+1 Query Problem Once and For All

Bon retour parmi nous, chers développeurs ! Si vous avez déjà créé une application avec Entity Framework Core, vous avez sans doute rencontré des goulets d’étranglement de performance qui vous ont laissé perplexe. Pourquoi une requête qui s’exécute instantanément en développement ralentit-elle brutalement en production ? Souvent, le coupable se cache en pleine vue : le fameux problème des requêtes N+1. Dans cet article, nous allons examiner en détail ce qui provoque ce tueur silencieux de performances, comment le détecter avant que vos utilisateurs ne le remarquent et comment le corriger efficacement grâce au chargement anticipé, aux projections et à des techniques d’optimisation judicieuses.

Avant d’entrer dans les détails techniques, je vous invite à écouter l’épisode de podcast associé : Improve Entity Framework Core Query Performance. Dans cet épisode, nous décortiquons plusieurs pièges courants d’Entity Framework et partageons des conseils concrets pour que vos applications restent extrêmement rapides.

Comprendre le problème des requêtes N+1

Qu’est-ce que N+1 ?

Le problème N+1 survient lorsque vous chargez des données liées d’une manière qui génère de nombreuses requêtes supplémentaires. Dans Entity Framework Core, cela apparaît souvent lorsque vous accédez à des données liées à l’intérieur d’une boucle. Par exemple, vous pouvez récupérer 100 commandes, puis, pour chaque commande, accéder à la propriété client. Cela déclenche une requête pour toutes les commandes, puis 100 requêtes supplémentaires, une pour chaque client. Vous vous retrouvez donc avec 101 requêtes au lieu d’une seule. Cela ralentit votre application, surtout lorsque les volumes de données sont importants. Ce problème peut passer inaperçu avec de petits jeux de données, mais il devient un véritable problème en production.

Détecter les requêtes N+1 en production

Vous pouvez repérer le problème N+1 en surveillant le nombre de requêtes que votre application envoie à la base de données. Voici quelques moyens de le détecter :

Activez la journalisation SQL pour voir chaque requête exécutée.
Utilisez des outils de profilage pour vérifier les performances des requêtes.
Surveillez le nombre de requêtes. Si vous constatez de nombreuses requêtes pour un résultat restreint, vous avez peut-être un problème N+1.
Testez votre application avec de grands jeux de données, semblables à ceux utilisés en production.

Astuce : vérifiez systématiquement vos journaux et vos outils de profilage après avoir ajouté de nouvelles requêtes ou modifié la manière de charger les données liées.

Corriger N+1 grâce au chargement anticipé

Vous pouvez corriger le problème N+1 dans Entity Framework Core en utilisant le chargement anticipé. Ce mécanisme vous permet de récupérer en une seule requête toutes les données dont vous avez besoin. Pour cela, utilisez la méthode Include. Elle indique à EF de joindre les tables liées et de tout récupérer d’un seul coup. Par exemple, si vous souhaitez obtenir des auteurs et leurs livres, vous pouvez écrire :

var authorsWithBooks = context.Authors.Include(a => a.Books).ToList();

Ce code exécute une seule requête qui joint les auteurs et les livres. Votre application obtient toutes les données en une fois. Le chargement anticipé réduit le nombre de requêtes et accélère votre application. Vous devriez l’utiliser lorsque vous savez que vous aurez besoin des données liées immédiatement. Cela vous permet d’éviter les ralentissements et de garantir le bon fonctionnement de votre application.

Suivi ou absence de suivi pour les performances

Entity Framework Core suit chaque entité que vous chargez. C’est le paramètre par défaut. Ce suivi permet à EF de savoir si vous modifiez quelque chose, mais il peut ralentir votre application. Il est plus lent avec de gros volumes de données, votre application peut consommer davantage de mémoire, et les requêtes peuvent prendre plus de temps lorsque le suivi est activé. Utiliser AsNoTracking rend les requêtes plus rapides et réduit la consommation de mémoire. Votre application peut ainsi répondre plus vite et servir davantage d’utilisateurs simultanément.

Astuce : si vous désactivez le suivi, vos requêtes s’exécutent plus rapidement. C’est idéal lorsque vous n’avez besoin que de lire des données.

Utilisez asnotracking si vous ne souhaitez pas mettre à jour ou supprimer les données. La plupart des API web ne font que lire des données. Environ 70 à 80 % des points de terminaison se contentent d’afficher des informations. Ceux-ci fonctionnent mieux avec asnotracking. Voici quelques situations où son utilisation est judicieuse :

Rapports et tableaux de bord qui ne font qu’afficher des données
Réponses d’API qui fournissent des listes ou des détails à afficher
Points de terminaison de recherche ou de filtrage qui ne font que lire la base de données

Pagination et grands volumes de données

Lorsque vous utilisez EF avec de grands volumes de données, vous pouvez rencontrer de sérieux problèmes. Charger trop de données en une seule fois peut ralentir votre application, voire la faire planter. Voici quelques conséquences possibles :

Votre application peut consommer trop de mémoire et manquer de ressources.
L’obtention des réponses peut prendre beaucoup de temps en raison du volume de données.
La base de données peut cesser de fonctionner si vous tentez de charger trop de données en une seule fois.

Vous pouvez résoudre ces problèmes en utilisant la pagination. La pagination découpe vos données en morceaux plus petits, ce qui rend votre application plus rapide et plus agréable à utiliser. Dans EF, vous pouvez y parvenir avec Skip() et Take(). Skip permet d’ignorer un certain nombre d’enregistrements. Take ne récupère que le nombre d’enregistrements souhaité. Cette approche facilite le traitement de grands volumes de données et garantit le bon fonctionnement de votre application.

Opérations en masse et regroupement par lots

Vous pouvez accélérer votre base de données grâce aux opérations en masse. Ces méthodes permettent de modifier de nombreux enregistrements en même temps. Les méthodes EF standard conviennent aux petits traitements, mais deviennent lentes dès que les volumes augmentent. Les opérations en masse permettent d’insérer, de mettre à jour ou de supprimer rapidement des milliers de lignes. Vous pouvez y recourir lors de l’importation de données depuis des fichiers CSV, lors de la synchronisation d’enregistrements ou pour les mises à jour nocturnes.

Le regroupement par lots permet de grouper des actions afin d’accélérer votre application. Vous pouvez utiliser des mises à jour par lots avec UpdateRange() pour modifier de nombreux éléments en une seule opération. Évitez d’appeler SaveChanges() trop souvent, car chaque appel envoie des données à la base de données. EF Core 7 introduit de nouvelles méthodes, comme ExecuteUpdate et ExecuteDelete, pour les modifications en masse.

Conclusion

Optimiser Entity Framework Core n'a pas à relever de la devinette. En comprenant comment se produit le problème de requêtes N+1, en utilisant des outils pour surveiller la génération de SQL, en recourant au chargement anticipé et aux requêtes sans suivi, et en intégrant la pagination et les opérations en masse, vous pouvez transformer une couche de données lente en un moteur performant. Mesurez toujours votre référence de performance de départ et testez vos requêtes de manière approfondie dans des conditions réalistes.

Pour aller encore plus loin dans ces stratégies, écoutez l’épisode complémentaire Improve Entity Framework Core Query Performance. Appliquer ces bonnes pratiques vous permettra d’éviter les goulets d’étranglement cachés et d’offrir une expérience fluide à vos utilisateurs !