SQL Server执行计划教会我如何创建索引?
2015-08-28来源:

名单

SQL Server 执行计划,是我们分析 SQL 执行情况的一大利器,通过它,我们也可以很方面的查看索引的执行,在实践之前,需要了解一些必备技能,以下知识点摘自-看懂 SqlServer 查询计划。

SQL Server 有二种索引:聚集索引和非聚集索引。二者的差别在于:【聚集索引】直接决定了记录的存放位置, 或者说:根据聚集索引可以直接获取到记录。【非聚集索引】保存了二个信息:1.相应索引字段的值,2.记录对应聚集索引的位置(如果表没有聚集索引则保存记录指针)。 因此,如果能通过【聚集索引】来查找记录,显然也是最快的。

SQL Server 会有以下方法来查找您需要的数据记录:

【Table Scan】:遍历整个表,查找所有匹配的记录行。这个操作将会一行一行的检查,当然,效率也是最差的。

【Index Scan】:根据索引,从表中过滤出来一部分记录,再查找所有匹配的记录行,显然比第一种方式的查找范围要小,因此比【Table Scan】要快。

【Index Seek】:根据索引,定位(获取)记录的存放位置,然后取得记录,因此,比起前二种方式会更快。

【Clustered Index Scan】:和【Table Scan】一样。注意:不要以为这里有个Index,就认为不一样了。 其实它的意思是说:按聚集索引来逐行扫描每一行记录,因为记录就是按聚集索引来顺序存放的。 而【Table Scan】只是说:要扫描的表没有聚集索引而已,因此这二个操作本质上也是一样的。

【Clustered Index Seek】:直接根据聚集索引获取记录,最快!

所以,当发现某个查询比较慢时,可以首先检查哪些操作的成本比较高,再看看那些操作在查找记录时, 是不是【Table Scan】或者【Clustered Index Scan】,如果确实和这二种操作类型有关,则要考虑增加索引来解决了。 不过,增加索引后,也会影响数据表的修改动作,因为修改数据表时,要更新相应字段的索引。所以索引过多,也会影响性能。 还有一种情况是不适合增加索引的:某个字段用0或1表示的状态。例如可能有绝大多数是1,那么此时加索引根本就没有意义。 这时只能考虑为0或者1这二种情况分开来保存了,分表或者分区都是不错的选择。

应用分析

我们先不建任何索引(除了主键 ID 的聚集索引),来看一下上面 SQL 代码,在 SQL Server 执行计划中的执行情况:

名单

从上面的执行计划中,我们可以很直观的看出差别,所以在写 SQL 的时候,一定要慎重啊,这边为了方便展示,我们还是以 ProduceTime 字段进行排序,按照 ID 排序,虽然没有了 SORT 性能开销,但是发现查询记录为“Clustered Index Scan”,这是全表查询的意思,我们理想的应该是“Index Seek”或者“Clustered Index Seek”,因为这种是按照索引查询,速度最快。按照我们程序员的理解,应该创建一个非聚集索引,比如下面 IX_Product_Provider_State 索引:

名单

“Index Seek”,这就是我们想要的效果,其实关于索引的创建有很多的现实问题,比如组合字段索引和单个字段索引有何不同?就像上面示例中的查询用例,如果 ProduceTime 排序在其他查询条件中也存在,是不是应该拉出来创建一个索引?还是像上面一样,和查询条件一起创建一个组合字段索引?还有一种情况就是,在一个应用程序查询中,存在单个字段的查询,也存在组合字段的查询,那这时候我们是创建单个字段索引?还是创建组合字段索引呢?这几个问题,你创建一下索引,然后用“ SQL 执行计划”试试就知道了。 总结 针对上面的查询用例,我个人觉得,最好的方案是:排序字段使用 ID,按照实际应用场景,提取出需要查询的字段,避免 SELECT *,这样会减少在添加“包含性 列”的字段,创建 IX_Product_Provider_State 非聚集索引,索引字段为:ProviderID 和 State,如果 State 的值不是多变的(比如值为 1 和 0),尽量不要创建 State 字段的非聚集索引。 做完这些,你会发现,你的应用程序像飞的一样。

更多信息请查看IT技术专栏

推荐信息
Baidu
map