这个问题是其他人问题的后续问题：尽管更新了统计信息和重新编译，但由于执行计划不同，添加 INNER JOIN 会破坏查询性能，为什么？
我的问题是关于执行计划的一小部分。
索引（节点 22）上的 Index Seek 运算符Events.nci_wi_...估计返回 77191 行。这是嵌套循环运算符（节点 19）的外部输入。内部输入是Locations.UC_LocationID（节点 23）上的索引查找。该节点的估计执行次数为2614。
我天真的理解是，由于嵌套循环在外部被输入 77191 行，因此它别无选择，只能执行内部运算符同样多次（至少使用内部连接逻辑运算符）。为什么这里有区别呢？
嵌套循环本身估计会返回 40 行。这比外部输入的行数少三个数量级。
我知道当 QO 需要统计估计匹配行数时这是可能的，但在这种特殊情况下，columnsEvents之间存在外键约束，并且if也存在。然后，我希望优化器假设，对于外部输入中的每一行，内部输入中恰好存在一行，嵌套循环的估计行数也应为 77191 行。为什么这里没有发生这种情况？Location(LocationId, TenantID)TenantIDLocationIDNOT NULLEvents
我也很好奇为什么在这种情况下选择嵌套循环以及为什么在排序时会发生溢出。