Course contentsShow
← C#
Lesson 1147 of 1,90810. Entity Framework Core ModelingFree lesson

Analyzing Execution Plans

Translate database engine execution plans back into performance-impacting EF Core code.

In this lesson, you will learn how to bridge the gap between a database engine's execution plan and your EF Core LINQ queries to identify performance bottlenecks.

When you execute a query, SQL Server generates an "execution plan"—a roadmap of how it retrieves your data. As an EF Core developer, you rarely see this plan directly in your IDE, but you can view it by enabling Database Profiling Best Practices via SQL Server Management Studio (SSMS) or Azure Data Studio.

Bridging the Plan to the Code

An execution plan often highlights "Table Scans" or "Index Scans," which are red flags indicating that the database is reading every row in a table. In EF Core, this often happens when your LINQ query lacks appropriate filtering or utilizes properties that aren't indexed.

For example, consider this LINQ query:

var results = context.Orders
    .Where(o => o.CustomerName == "Alice")
    .ToList();

If the execution plan shows a Clustered Index Scan, it means the engine had to check every single order to find "Alice." If you see this, you translate the plan back into EF Core by ensuring CustomerName is properly indexed in your database migration snapshots.

Another common issue is the Key Lookup or RID Lookup, which occurs when your query selects columns not covered by an existing index. If the plan shows a heavy cost for these lookups, it means your EF Core query is fetching too many columns (e.g., context.Orders.ToList()), forcing the engine to hop between the index and the full data row. You can resolve this by applying Query Result Materialization techniques, such as using .Select() to return only the specific DTO properties you actually need.

Why this matters

By analyzing the plan, you stop guessing why a query is slow. You look for the "High Cost" operators and work backward: does the query need a missing index? Is it causing an unexpected JOIN due to how navigation properties are configured? Does it need an explicit Include() to avoid N+1 query issues? The execution plan is the "truth" of your EF Core code's impact on the database server.

Key Takeaway: Use the execution plan to identify high-cost operators like Table Scans or Key Lookups, then refine your LINQ queries or indexes to match the database's ideal retrieval path.