问题是用于验证外键的聚集索引扫描.

The issue is the clustered index scan to validate the foreign key.

当删除成功并且没有匹配的记录会导致违规时，则需要扫描所有table2.该表有 1,117,190 行，因此这是一项开销很大的操作，绝对可以从索引中受益.

When the delete succeeds and there are no matching records that would cause a violation then all of table2 needs to be scanned. This table has 1,117,190 rows so this is an expensive operation that could definitely benefit from an index.

执行计划中显示的 10% 数字只是基于某些建模假设的估计.

The 10% figure shown in the execution plan is just an estimate based on certain modelling assumptions.

整个计划的成本为 0.0369164，表 2 上的扫描成本为 0.0036199，其余所有费用为 0.0332965.但是请注意，对于聚集索引扫描运算符，估计 CPU 成本为 1.22907，估计 IO 成本为 10.7142(总计 11.94327 而不是 0.0369164).

The entire plan is costed at 0.0369164 with the scan on table 2 costed at 0.0036199 and everything else accounting for the remaining 0.0332965. However notice that for the clustered index scan operator the Estimated CPU Cost is 1.22907 and Estimated IO Cost is 10.7142 (totaling 11.94327 not 0.0369164).

这种差异的原因是扫描是在反半连接运算符下进行的，一旦找到匹配的行，扫描就会停止.估计子树成本在建模假设下按比例缩小，即这将在仅扫描表的很小一部分后发生.

The reason for this discrepancy is that the scan is under an anti semi join operator and the scan can stop as soon as a matching row is found. The estimated subtree cost is scaled down under the modelling assumption that this will happen after only a very small proportion of the table has been scanned.

如果没有 FK 违规并且删除成功，则需要扫描整个表，因此使用未按比例缩小的数字会提供更多信息.

In the case that there are no FK violations and the delete succeeds then the entire table needs to be scanned so it would be more informative to use the unscaled down figure.

如果使用 11.94327 成本重新计算百分比，该操作代表实际发生的完整扫描，则该扫描操作显示为计划成本的 99.7% (11.94327/(11.94327 + 0.0332965)).

If the percentages are reworked out using the 11.94327 cost for that operator that represents the full scan that happened in practice then this scan operator shows up as being 99.7% of the plan cost (11.94327 / (11.94327 + 0.0332965)).