Assume that you have a table using a foreign key constraint set to cascade delete, and the statistics on the foreign key column don't cover the entire range of the key values in the table (for example: because statistics were not updated after data distribution changes to the table). In this scenario, when you try to delete a row corresponding to a key value not represented in the statistics histogram, and the Query Optimizer is using the default cardinality estimation, the delete operation is slower than expected. You may also notice an index scan operation is used to find the matching rows in the referencing table.


Microsoft has confirmed that this is a problem in the Microsoft products that are listed in the "Applies to" section.


This issue is fixed in the following cumulative updates for SQL Server:

Note: This fix is only enabled when you turn optimizer hotfixes ON (either through the database scoped configuration option, query hint or trace flag 4199).

About cumulative updates for SQL Server:

Each new cumulative update for SQL Server contains all the hotfixes and all the security fixes that were included with the previous cumulative update. Check out the latest cumulative updates for SQL Server:


To work around this issue, use one of the following methods:

  • Use legacy cardinality estimation. For more information, see Cardinality Estimation (SQL Server).

  • Remove the cascade delete from the Foreign Key definition, and perform the delete operation by using JOIN between parent and child tables to accomplish the equivalent of cascade delete.

  • Update statistics on the parent table with FULLSCAN before deleting data.


Learn about the terminology that Microsoft uses to describe software updates.

Need more help?

Expand your skills
Explore Training
Get new features first
Join Microsoft Insiders

Was this information helpful?

What affected your experience?

Thank you for your feedback!