Query Optimizer估计，当实际行数为2000时，联接的结果将只有一行。这导致数据集上的后续联接的估计结果为一行，而其中某些联接则达到了很高的水平。 30,000

由于计数为1，因此QO为许多联接选择了一个循环联接/索引查找策略，这太慢了。我通过使用`WITH OPTION(HASH JOIN，MERGE JOIN)'限制了可能的加入策略来解决了这个问题，该方法将整体执行时间从60分钟以上提高到了12秒。但是，由于行计数不好，我认为QO仍无法生成最佳计划。我不想手动指定连接顺序和详细信息-受此影响的查询太多，因此不值得。

在Microsoft SQL Server 2000中，这是一个具有多个表选择的中等查询，这些表选择已联接到主选择中。

我认为QO可能会高估联接中许多方面的基数，期望表之间的联接列共有较少的行。

通过扫描联接之前的索引估算的行数是准确的，仅是某些联接之后估算的行数太低了。

数据库中所有表的统计信息都是最新的，并会自动刷新。

早期的不良连接之一是在通用的"人"表中，该表提供了所有人共有的信息，而该人的专用表中约有5％属于这些人。两个表(和联接列)中的群集PK是一个INT。该数据库已高度规范化。

我相信根本的问题是某些连接后行数估计错误，所以我的主要问题是：

• 如何确定QO的加入后行数估算值？
• 有没有一种方法可以暗示联接将有很多行而无需手动指定整个联接顺序？

解决方案

我们是否不能使用适当放置的查询提示来生成QO？

尽管统计信息是最新的，但扫描百分比仍不足以提供准确的信息。我在每个基本表上都运行了此问题，该基本表在通过扫描所有行(而不仅仅是默认百分比)来更新表上的所有统计信息时遇到问题。

UPDATE STATISTICS <table> WITH FULLSCAN, ALL

该查询仍然具有大量的循环联接，但是联接顺序不同，并且在2-3秒内运行。