记SQL SERVER一次诡异的优化

时间:2022-11-10 11:27:37

  最近做的项目快上线了,在做了一次压力测试后发现了不少问题,基本都是因为数据量达到一定级别时(预测系统上线10年后的数据量)SQL查询超时,其中有些是因为索引缺失、有些是因为写法不好,这些在有经验的人眼里一眼就能看出问题,于是我解决起来都很快。

  但其中有一个无比诡异,SQL很简单,但执行起来都超过1分钟,而我们的理想目标是1秒,差距很大。

  先简单写下这个SQL的样子:

SELECT TOP 10
T1.C1, T1.C2, T1.C3
FROM TABLE_1 T1
JOIN TABLE_2 T2
ON T1.C1 = T2.C1
WHERE
T2.C2 NOT IN ('V1', 'V2', 'V3')

  首先看到这么简单,速度慢的问题比较容易出现在NOT IN,这个不能索引速度很慢,但需求上的原因,要么我们换其他方式实现NOT IN,耗费时间去设计重构,但当天就要发版本时间不允许。SQL就这么简单,索引都OK,问题出在哪里呢?

  就不拐弯抹角了,我尝试去掉了TOP 10,奇迹出现了,执行1秒都不要就完成了!TOP 10?尼肿么辣!!

  问题找到了,原因还不明,立刻想解决方案,第一顺位想到的就是不做TOP 10都取出来程序在内存处理TOP 10,当然这个方案很让人不爽!

  第二就是网上找找资料,发现一个帖子说TOP有时候会影响SQL的优化计划芸芸,这个应该就是原因了,但用执行计划分析器却没有发现什么异常,只能说诡异。

  然后我尝试使用“SQL SERVER 强制执行计划”关键字搜索,看到一篇文章,内容不是我想要的,但我看到一个SQL的关键字OPTION(FORCE ORDER),看到Force这个词我觉得可能是我要找的东西,于是我把这句设置加到了我的SQL最后面,终于,执行速度变为了不到1秒,但原理还没有弄的一清二楚,就先用这个吧,加一句话解决了紧急的问题,非常开心,有空再来研究这个是什么原理,周末的同事有教过SQL的都没见过这种用法。