Fix EF Core Performance Pitfalls That Slow Down C# Apps (2026)

EF Core intermittently throws System.Data.SqlClient.SqlException with error code 8629 and the message "The query processor could not produce a query plan. No plan could be found for the query. The query has been aborted." This happens under load, particularly when executing complex queries or when many concurrent requests hit the database. The core issue is that the SQL Server query optimizer is failing to generate an execution plan for certain EF Core generated queries, leading to query abortion.

Here are the common causes and their fixes:

1. Parameter Sniffing Issues

   • Diagnosis: This is the most frequent culprit. SQL Server tries to create a generic plan based on the first execution of a query, using the specific parameter values from that execution. If subsequent executions use drastically different parameter values, the cached plan can be highly inefficient or, in rare cases, impossible to use, leading to error 8629. You can identify this by looking at the execution plan for the problematic query in SQL Server Management Studio (SSMS) and seeing a high estimated cost or a plan that’s clearly not optimized for the current parameter values.
   • Fix: Use the OPTION (RECOMPILE) query hint. In EF Core, you can apply this using FromSqlRaw or ExecuteSqlRaw for raw SQL, or by using WithExecutionStrategy with a custom strategy that appends the hint. For LINQ, it’s trickier. A common workaround is to break complex LINQ into smaller, more specific queries or use stored procedures. If you must use LINQ and suspect parameter sniffing, consider forcing a recompile for specific, problematic queries:

     // Example for a complex LINQ query that might be affected
     var results = await _context.Orders
         .Where(o => o.CustomerId == customerId && o.OrderDate >= startDate && o.OrderDate <= endDate)
         .OrderBy(o => o.OrderDate)
         .ToListAsync();
     
     // To force recompile (requires advanced technique or breaking to raw SQL)
     // Forcing recompile for LINQ is not directly supported as a simple attribute.
     // The most common approach is to use FromSqlRaw or a stored procedure.
     // If you're using FromSqlRaw:
     var results = await _context.Orders
         .FromSqlRaw("SELECT * FROM Orders WHERE CustomerId = {0} AND OrderDate >= {1} AND OrderDate <= {2} ORDER BY OrderDate OPTION (RECOMPILE)", customerId, startDate, endDate)
         .ToListAsync();
     

   • Why it works: OPTION (RECOMPILE) tells SQL Server to generate a new execution plan every time the query is executed, using the current parameter values. This eliminates the problem of a stale, inefficient cached plan.

2. Index Fragmentation

   • Diagnosis: Heavily fragmented indexes can cause SQL Server to perform more I/O than necessary, leading to slower query execution. While not a direct cause of error 8629, it can exacerbate performance issues that indirectly contribute to the optimizer’s struggle. Check index fragmentation levels in SSMS using sys.dm_db_index_physical_stats.
   • Fix: Reorganize or rebuild fragmented indexes. For indexes with less than 30% fragmentation, ALTER INDEX ... REORGANIZE is sufficient. For higher fragmentation (over 30%), ALTER INDEX ... REBUILD is recommended.

     -- Example for reorganizing an index
     ALTER INDEX IX_Customer_Name ON Customers REORGANIZE;
     
     -- Example for rebuilding an index
     ALTER INDEX IX_OrderDate ON Orders REBUILD;
     

   • Why it works: Reorganizing and rebuilding indexes defragments them, making data retrieval more efficient by reducing the number of page reads required.

3. Outdated Statistics

   • Diagnosis: The query optimizer relies on statistics about the data distribution in your tables to make informed decisions about query plans. If statistics are outdated, the optimizer might make poor choices. SQL Server automatically updates statistics, but sometimes manual intervention is needed, especially after large data modifications.
   • Fix: Update statistics for the relevant tables. You can do this manually or schedule automatic updates.

     -- Update statistics for a specific table
     UPDATE STATISTICS Orders WITH FULLSCAN;
     
     -- Or update statistics for all tables
     EXEC sp_updatestats;
     

   • Why it works: Fresh statistics provide the query optimizer with accurate information about data cardinality and distribution, enabling it to generate more optimal query plans.

4. Complex or Unparameterized Queries Generated by EF Core

   • Diagnosis: Extremely complex LINQ queries, especially those involving multiple joins, subqueries, or conditional logic, can sometimes generate SQL that is difficult for the SQL Server optimizer to handle. This is more likely to happen when EF Core’s query translation isn’t as efficient as hand-written SQL.
   • Fix: Simplify your LINQ queries. Break them down into smaller, more manageable queries. Consider using projection (.Select()) to fetch only the necessary data. If simplification isn’t feasible, resort to stored procedures or FromSqlRaw for these specific, problematic queries.

     // Instead of a massive query:
     // var complexResults = await _context.Products
     //     .Where(p => p.Category.Name == "Electronics" && p.Supplier.Country == "USA" && p.Price > 100)
     //     .Select(p => new { p.Name, p.Price, p.Category.Name, p.Supplier.CompanyName })
     //     .ToListAsync();
     
     // Break it down or use FromSqlRaw if performance is critical:
     var productIds = await _context.Products
         .Where(p => p.Category.Name == "Electronics" && p.Supplier.Country == "USA" && p.Price > 100)
         .Select(p => p.ProductId)
         .ToListAsync();
     
     var detailedProducts = await _context.Products
         .Where(p => productIds.Contains(p.ProductId))
         .Select(p => new { p.Name, p.Price, p.Category.Name, p.Supplier.CompanyName })
         .ToListAsync();
     

   • Why it works: Simpler queries are easier for the optimizer to analyze and generate plans for. Projection reduces the amount of data processed and transferred.

5. SQL Server Version or Configuration Issues

   • Diagnosis: Older versions of SQL Server might have less sophisticated query optimizers. Certain database-level settings or compatibility levels can also affect query plan generation.
   • Fix: Ensure you are using a supported and reasonably recent version of SQL Server. Check the compatibility level of your database. Sometimes, changing the compatibility level to a newer version (e.g., from 110 to 130 or higher) can resolve optimizer issues, but this should be done with thorough testing as it can affect other queries.

     -- Example: Changing compatibility level
     ALTER DATABASE YourDatabaseName SET COMPATIBILITY_LEVEL = 150; -- Use a level appropriate for your SQL Server version
     

   • Why it works: Newer SQL Server versions and higher compatibility levels often include improvements to the query optimizer that can better handle complex or dynamic queries.

6. High Server Load and Resource Contention

   • Diagnosis: When the SQL Server is under heavy load (CPU, memory, I/O), the query optimizer might struggle to complete its work within reasonable time limits, leading to timeouts or plan generation failures. Monitor SQL Server performance counters.
   • Fix: Optimize the SQL Server environment. This could involve scaling up hardware, optimizing other running queries, or implementing connection pooling more effectively at the application level.
   • Why it works: Reducing contention for server resources allows the query optimizer to function more reliably and quickly.

The next error you’re likely to encounter after fixing these issues is a different, more specific performance bottleneck, such as a Timeout expired error if queries are still too slow, or a Deadlock victim error if concurrent access patterns are problematic.