可惜证据文档取不出来,而且冗长,就大致做个备忘录,有心的人看看就明白了。
1. 条件里没有子查询 -> 短路评价
SELECT * FROM test WHERE some_fast_check()=1 OR some_slow_check(c) = 1
2. 条件里有子查询,但子查询是针对真实表的 -> 准“短路评价”
SELECT * FROM test WHERE some_fast_check()=1 OR c IN (SELECT * FROM normal_or_temp_table)
需要注意的是:子查询一定会最先执行,相当于先做成一个内存表,勉强说得过去,但是万一这个子查询很慢,偏偏第一个条件已经满足了的时候,那就悲剧了,拖累了整个速度。
的确,如果第一个条件满足的话,这之后对于形成的内存表进行Scan的次数=0,所以说这是准 “短路评价”。
3. 条件里有子查询,且使用了“表函数” -> 开始失去控制了。
SELECT * FROM test WHERE some_fast_check()=1 OR c IN (SELECT * FROM some_slow_data())
尤其是上述例子里“标量函数”和“表函数”混合的,是最超乎想象的,这时,
some_slow_data()表函数一定最先被执行一次以便其产生内存表,这个只好忍了。
但是这之后就不可忍了!对于这个内存表,总会被进行N次Scan,而N显然取决于主表里符合其他条件的件数。
就是说就算所有行的some_fast_check()=1已经为true了,这后面针对内存表的Scan还是继续做!
傻啊。没办法,从Plan看就是这样的,SQL Server就是这么任性。
当然,结果速度快不快,还要取决于优化器否决定并发执行,有时也不慢。
4. 短路评价大杀器"CASE WHEN"
例如把下面这句整体当做一个表达式来评价时,当"快速条件"满足了时,整个表达式就出结果(1)了,"慢速条件"都不会被执行,
CASE WHEN 快速条件 THEN 1 WHEN 慢速条件 THEN 1 ELSE 0 END
于是,整个SQL改成:
SELECT * FROM test WHERE
CASE WHEN some_fast_check()=1 THEN 1
WHEN c IN (SELECT * FROM some_slow_data()) THEN 1
ELSE 0
END = 1
就可以变快了。
还有,不知道DB为什么没有默认开启RECOMPILE选项,这个选项会减少哪些不必要的子查询。
测试时,必须注意用dbcc命令清楚缓存,具体的命令一查就行。
另外一个确定的经验是,IN换成EXISTS或者TABLE JOIN的方式在第一次执行时(没有缓存),Plan是一样的,后来有了Cache之后,TABLE JOIN方式就快些。