SQL Server的WHERE条件"短路评价"大杀器CASE WHEN

2019独角兽企业重金招聘Python工程师标准>>>

可惜证据文档取不出来，而且冗长，就大致做个备忘录，有心的人看看就明白了。

---

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方式就快些。

转载于:https://my.oschina.net/osexp2003/blog/689217