当实际行数为 2000 时，查询优化器估计联接结果只有一行。这导致数据集上的后续联接的估计结果只有一行，而其中一些联接的结果却高达 2000 30,000。
计数为 1 时，QO 正在为许多连接选择循环连接/索引查找策略，这太慢了。我通过限制可能的加入策略来解决这个问题WITH OPTION (HASH JOIN, MERGE JOIN)，这将整体执行时间从 60 多分钟缩短到 12 秒。然而，我认为由于行数错误，QO 仍然生成了一个不太理想的计划。我不想手动指定连接顺序和详细信息——受此影响的查询太多，因此不值得。
这是 Microsoft SQL Server 2000 中的一个中等查询，其中多个表选择连接到主选择。
我认为 QO 可能高估了联接中多方的基数，期望表之间的联接列具有更少的公共行。
在连接之前扫描索引的估计行数是准确的，只是某些连接之后的估计行数太低了。
数据库中所有表的统计信息都是最新的并自动刷新。
早期的不良联接之一是在一个通用“Person”表（用于所有人共有的信息）和一个专门的人员表（所有这些人中大约 5% 属于该表）之间。两个表（以及连接列）中的聚簇 PK 都是 INT。该数据库是高度规范化的。
我认为根本问题是某些连接后行数估计错误，所以我的主要问题是：
- 如何修复 QO 的连接后行计数估计？
- 有没有一种方法可以暗示连接将有很多行，而无需手动指定整个连接顺序？
尽管统计数据是最新的，但扫描百分比还不够高，无法提供准确的信息。我在每个有问题的基表上运行了这个，通过扫描所有行（而不仅仅是默认百分比）来更新表上的所有统计信息。
UPDATE STATISTICS <table> WITH FULLSCAN, ALL
该查询仍然有很多循环连接，但连接顺序不同，并且运行时间为 2-3 秒。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
