记SQL SERVER一次诡异的优化

　　最近做的项目快上线了，在做了一次压力测试后发现了不少问题，基本都是因为数据量达到一定级别时（预测系统上线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的都没见过这种用法。