注意：如果有的话， 该表的所有查询/更新前运行的查询计划和/或所有这些表的更新前optdiag输出？

注意：我目前没有时间仔细阅读整个dbcc跟踪标志输出集，以此类推...

----------------

（明显的）时间消耗者是CUSTOMER_PNI_LINK的5.33亿个lios ...每次扫描需要约25 lios； 而对CUSTOMER_PNI_LINK的后续打击每次扫描只需要5 lios； 对我来说，这似乎表明HQ_CUSTOMER_ID列的数据分布不均（例如，大量的NULL，大量的1等）。

另一个（显而易见的）问题是查询的两个主要块的连接顺序不同。

----------------

假设实际的查询和/或数据没有变化，唯一的变化是统计信息，但无法访问实际的统计信息（例如，所有有问题的表的optdiag），我想您可能已经 在某些统计数据中存在一些偏差，这可能导致优化程序在某些联接订单上表现出比真实情况更好的性能。

是否有机会在过去某个时刻有人手动或作为脚本化"更新统计信息"工作的一部分运行" sp_modify_stats/REMOVE_SKEW_FROM_DENSITY"调用？ [在这里可以方便地查看'optdiag'输出，尤其是更新之前的统计信息和更新之后的统计信息。] [只要您有最新的'更新统计信息'命令的输出，... 会寻找任何表明修改后的统计信息被覆盖/丢失的消息。]

----------------

虽然当前的性能可能不是问题（因为该查询以前应该可以正常工作），但我可能想看看是否/如何简化查询...

由于2x顶级" exists"子查询的CPL <-> BAS <-> IOR部分看起来相同，因此我可能想研究是否可以重写查询以消除一组 这些联接（并可能减少优化器的工作量，从而可能改善最终的查询计划...？），例如：

 CU
 ...剪...
 并存在（CPL <-> BAS <-> IOR
                ...剪...
                和（存在（IOR1 <-> CU1>）
                      或（不存在（IOR1 <-> CU1）
                          并且存在（CU2）
                         ）
                    ）
            ）