我有一个相当复杂的SQL查询，涉及多个子查询和联合。尽管很复杂，但子查询部分执行得非常快（编译后<1ms）。但是，当我整个查询运行时，它需要超过60毫秒。
我使用了“set statistics time on”和“set statistics io on”来跟踪基表的访问，而SQL正在执行比必要更多的逻辑读取。当我自己运行子查询时，它只执行10次读取，但是当整个查询运行时大约是1800次。
我想鼓励SQL首先评估子查询 - 预期的行数为1-5，因此数据集很小。然后它应该是内部连接到同一个基表，然后撤回估计的10-20个记录。
有没有办法使用提示来确保SQL针对预期的情况进行优化？对于优化器来说，查询逻辑似乎太过分了，而且它选择的执行计划只适用于比我的情况更大的行集。
编辑：最终连接中的一个条件将过滤掉基表中99.99％的行。如果我可以强制SQL首先评估它，它应该做的伎俩。有没有办法做到这一点？
在此处查询文字：http://pastebin.com/zVR91AP2
在结尾处的WHERE子句被注释掉后，查询返回4行并以＆lt; 1ms运行，其中33个逻辑读取的审计表。 但是，如果我取消注释WHERE子句，它将返回3行（1个已过滤掉），并且需要50ms，并且审计表的读取次数高达1277次。 io统计信息表明工作表在第一个实例中使用，但在第二个实例中不使用。我想鼓励SQL使用这个工作表。
答案 0 :(得分：0)
解决了这个问题。解决方案是使用连接提示，在将查询连接到更大的表之前强制评估内部查询。
内部REMOTE加入dbo.poAudit ......等