马克你好，

确实，我附上以下内容供参考

1>问题查询（SP的一部分卡在982行）

2>我运行了带有调整参数的查询，供专家分析和帮助我（plancost，io，time，showplan和dbcc跟踪标志）

我将结果分为2个文件。 为了获得最佳格式，请打开docx格式的文件。 batch-analysis-tracing-part-1.txt batch-analysis-tracing-part-2-continuation.txt

请将完整的查询计划剪切-粘贴到* txt文件中，然后附加到您的问题上。

如前所述，查询计划看起来像是一个冗长的句子……无法阅读……而且我怀疑许多人会愿意花时间重新编辑以使其可读。

如果要提供查询的全文（在第982行），也可以作为附件（以提高可读性），可能也有帮助。

注意：如果有的话， 该表的所有查询/更新前运行的查询计划和/或所有这些表的更新前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）
                         ）
                    ）
            ）

由于此查询位于存储的proc中，因此要考虑的另一种可能性是，（针对proc的）不同的输入参数可能会导致生成不同的查询计划。

由于存储过程的好处之一是对调用#2-#n的查询计划的重用，因此您将需要排除在调用中重复使用"不良"查询计划的问题调用的任何问题 先前的调用。

一种方法是让您的批处理过程基于"当前"输入参数集（在执行时）强制重新编译proc，例如：

 exec    ... 可以重新编译

Hi Mark，

我没有以前的计划。

此外，sp_modifystats尚未用于此数据库。

代码更改也不是一种选择，因为我们谈论的是旧版应用程序，并且不再允许更改代码。

但是，我尝试了几件事，

1>我对查询中的所有相关表进行了重组，希望它能选择出最好的计划，但没有用

2>如果将forceplan设置为on，则优化程序将选择正确的计划，并且我会在几秒钟内获得预期的输出。

如何强制优化器选择通过forceplan on option生成的正确计划。

谢谢。