You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
> Since version 3.0.0, each `Include` will cause an additional JOIN to be added to SQL queries produced by relational providers, whereas previous versions generated additional SQL queries. This can significantly change the performance of your queries, for better or worse. In particular, LINQ queries with an exceedingly high number of `Include` operators may need to be broken down into multiple separate LINQ queries in order to avoid the cartesian explosion problem.
51
+
### Single and split queries
52
+
53
+
> [!NOTE]
54
+
> This feature is introduced in EF Core 5.0.
55
+
56
+
In relational databases, all related entities are by default loaded by introducing JOINs:
LEFT JOIN [Post] AS [p] ON [b].[BlogId] = [p].[BlogId]
62
+
ORDER BY [b].[BlogId], [p].[PostId]
63
+
```
64
+
65
+
If a typical blog has multiple related posts, rows for these posts will duplicate the blog's information, leading to the so-called "cartesian explosion" problem. As more one-to-many relationships are loaded, the amount of duplicated data may grow and adversely affect the performance of your application.
66
+
67
+
EF allows you to specify that a given LINQ query should be *split* into multiple SQL queries. Instead of JOINs, split queries perform an additional SQL query for each included one-to-many navigation:
INNER JOIN [Post] AS [p] ON [b].[BlogId] = [p].[BlogId]
81
+
ORDER BY [b].[BlogId]
82
+
```
83
+
84
+
While this avoids the performance issues associated with JOINs and cartesian explosion, it also has some drawbacks:
85
+
86
+
* While most databases guarantee data consistency for single queries, no such guarantees exist for multiple queries. This means that if the database is being updated concurrently as your queries are being executed, resulting data may not be consistent. This may be mitigated by wrapping the queries in a serializable or snapshot transaction, although this may create performance issues of its own. Consult your database's documentation for more details.
87
+
* Each query currently implies an additional network roundtrip to your database; this can degrade performance, especially where latency to the database is high (e.g. cloud services). EF Core will improve this in the future by batching the queries into a single roundtrip.
88
+
* While some databases allow consuming the results of multiple queries at the same time (SQL Server with MARS, Sqlite), most allow only a single query to be active at any given point. This means that all results from earlier queries must be buffered in your application's memory before executing later queries, increasing your memory requirements in a potentially significant way.
89
+
90
+
Unfortunately, there isn't one strategy for loading related entities that fits all scenarios. Carefully consider the advantages and disadvantages of single and split queries, and select the one that fits your needs.
91
+
92
+
> [!NOTE]
93
+
> One-to-one related entities are always loaded via JOINs, as this has no performance impact.
94
+
>
95
+
> At the moment, use of query splitting on SQL Server requires settings `MultipleActiveResultSets=true` in your connection string. This requirement will be removed in a future preview.
96
+
>
97
+
> Future previews of EF Core 5.0 will allow specifying query splitting as the default for your context.
0 commit comments