SQL Server后联接行计数低估

查询优化器估计,当实际行数为2000时,联接的结果将只有一行。这将导致数据集上的后续联接具有一行的估计结果,其中一些行的估计结果高达30000。

当计数为1时,QO正在为太慢的许多联接选择循环联接/索引查找策略。我通过使用 WITH OPTION (HASH JOIN, MERGE JOIN) 将总执行时间从60分钟提高到12秒。但是,我认为由于行数不好,QO仍在生成一个不太理想的计划。我不想手动指定联接顺序和详细信息——受此影响的查询太多,因此不值得这样做。

这是在Microsoft SQL Server 2000中,一个包含多个表选择的中等查询已加入到主选择中。

我认为QO可能高估了联接中多端的基数,期望表之间的联接列具有较少的共同行。

在联接之前扫描索引得到的估计行数是准确的,只有在某些联接之后的估计行数太低。

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

早期不好的连接之一是在一个通用的“人员”表(用于所有人共享的信息)和一个专用的人员表(这些人中约有5%属于该表)之间进行连接。两个表(和联接列)中的集群pk都是int。数据库高度规范化。

我认为根问题是某些连接后的错误行数估计,所以我的主要问题是:

• 如何修复QO的加入后行数估计?
• 有没有一种方法可以提示一个联接将有很多行而不手动指定整个联接顺序?