当实际行数为2000时，查询优化器估计连接的结果只有一行。这导致数据集的后续连接具有一行的估计结果，其中一些高达30,000。
计数为1时，QO为许多连接选择循环连接/索引搜索策略，这种策略太慢了。我通过使用WITH OPTION (HASH JOIN, MERGE JOIN)限制可能的连接策略来解决这个问题，这将整体执行时间从60多分钟提高到12秒。但是，由于行数不佳，我认为QO仍然会产生一个不太理想的计划。我不想手动指定连接顺序和详细信息 - 有太多的查询受此影响，因为它值得。
这是在Microsoft SQL Server 2000中，一个中等查询，其中有几个表选择连接到主选择。
我认为QO可能高估了连接中许多方的基数，期望表之间的连接列具有较少的共同行。
在连接之前扫描索引的估计行数是准确的，它只是在某些连接之后估计的行数过低。
数据库中所有表的统计信息都是最新的，并自动刷新。
早期不良联接之一是在一个通用的“人”表之间，用于所有人共有的信息，以及一个专门的人员表，约占所有人所属的5％。两个表（和连接列）中的聚簇PK是INT。数据库高度标准化。
我认为根问题是某些连接后的行数估计错误，所以我的主要问题是：
答案 0 :(得分：3)
虽然统计数据是最新的，但扫描百分比不足以提供准确的信息。我在每个基表上都运行了这个问题，通过扫描所有行来更新表上的所有统计信息，而不仅仅是默认百分比。
UPDATE STATISTICS <table> WITH FULLSCAN, ALL
查询仍然有很多循环连接，但连接顺序不同，它在2-3秒内运行。
答案 1 :(得分：0)
你不能用精心设置的查询提示来刺激QO吗？