我有一个相当复杂的 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 行并在 <1ms 内运行，对审计表进行了 33 次逻辑读取。但是，如果我取消注释 WHERE 子句，它会返回 3 行（过滤掉 1 行）并花费 50 毫秒，对审计表进行高达 1277 次逻辑读取。io stats 表明一个工作表在第一个实例中被使用，但不是在第二个实例中。我想鼓励 SQL 使用这个工作表。