MSSQL中SELECT TOP 1 比不加TOP 1 慢的原因分析以及SELECT TOP 1语句执行计划预估原理

现实中遇到过到这么一种情况：
　　在某些特殊场景下:进行查询的时候，加了TOP 1比不加TOP 1要慢（而且是慢很多）的情况，
　　也就是说对于符合条件的某种的数据，查询1条（符合该条件）数据比查询所有（符合该条件）数据慢的情况，
　　这种情况往往只有在某些特殊条件下会出现，那么，就有两个问题：为什么加了TOP 1 会比不加TOP 1慢？这种“特殊条件”是什么条件？
　　本文将对此情况进行演示和原理分析，以及针对此种情况采用什么方法来解决。

按照一贯风格，先造一个测试环境：1000W+的数据
数据的特点为：
1，表中有一个状态列BusinessStatus ，这个列的分布为1,2,3,4,5
2，表中有一个 业务ID列BusinessId ， BusinessId列是呈递增趋势

另外，在此表中查询一小部分BusinessStatus=0的分布较少的数据，且分布在最大的BusinessId上，这里暂定为5000行，利用如下脚本生成　

　　现在这个测试环境已经搭建完成，现在创建两个非聚集索引，一个是在BusinessStatus上，一个是在BusinessId

下面开始测试：

　　说明：1，以下测试，不用考虑缓存之类的因素，本机测试，内存也足够大，全部缓存这么点数据还是够的。也暂不分析IO具体值，粗看执行时间已经很明显了
　　　　　2，读者要对SQL Server索引结构，统计信息，执行计划，执行计划预估等知识有一定的认识，否则很多理论上的东西就看的云里雾里
　　　　　3，本文测试数据库为SQL Server 2012，SQL Server每个版本的预估算法可能都不一样，具体环境具体分析

SELECT TOP 1 比不加 TOP 1慢

　　1，首先执行TOP 1 *的查询，耗时13秒

　2，然后执行不加TOP 1 的查询，也即SELECT ，如下，耗时0秒（当然不是0秒，意思是很快就可以完成这个查询）

　　3，上面两个查询就可以重现第一个问题了，也就是说在当前这种查询条件下，TOP 1要比不加TOP 1慢很多　　

　　　　分析两者的执行计划：

　　　　首先看加了 TOP 1 的执行计划：可以看到走的是idx_BusinessId的索引扫描

　　　　接着看不加TOP 1 的执行计划：可以看到走的是idx_BusinessStatus这个索引的索引查找

　　　 原因分析：

　　　　那么为什么加了TOP 1就走BusinessId列上的索引扫描，不加TOP 1就走BusinessStatus上的索引扫描？
　　　　因为在加了TOP 1之后，只要求返回一条数据，
　　　　优化器认为（应该说是误认为）可以很快找到符合条件的那条记录，采用了idx_BusinessId列上的索引扫描
　　　　由于数据的分布可知，符合BusinessStatus=0的BusinessId，是分布在BusinessId值最大的一小部分数据中，而BusinessId又是递增的，
　　　　也就是说复合条件的数据是集中分布在idx_BusinessId索引树的一个很小的特定区域，
　　　　采用的是与idx_BusinessId顺序一致的（ForWard顺序）索引扫描，有数据分布特点可知，一开始找到的绝大多数的BusinessId，都不是符合BusinessStatus=0的
　　　　以至于几乎要扫描整个idx_BusinessId索引树才能找到符合BusinessStatus=0条件的数据，因此效率就会很低
　　　　反观不加TOP 1的时候，因为是要找所有符合BusinessStatus=0的数据，优化器就索引采取了idx_BusinessStatus索引查找的方式，至此，原因大概是这样的。

问题到这里才刚刚开始

后续精彩内容已被小麦苗无情隐藏，请输入验证码解锁本站所有文章

验证码：

请关注本站微信公众号，回复“小麦苗博客”，获取验证码。在微信里搜索“DB宝”或者“www_xmmup_com”或者微信扫描右侧二维码都可以关注本站微信公众号。