3.2 “缺失”的索引

3.2  “缺失”的索引

3.2.1  索引查找与索引扫描

(1)对于堆数据表

  如果数据表是一个堆结构,在使用 SELECT 语句访问堆表时,查询执行计划只有一个表扫描(Table Scan)。表扫描意味着必须扫描整张表,表的数据量越多,查询开销越大。

  如果在堆上创建合适的非聚集索引,可以有效地降低查询开销。查询执行计划可以通过索引查找(Index Seek)在叶级找到一个指向数据行的指针,然后通过这个指针在堆上迅速找到数据行。

(2)对于聚集索引表

  如果数据表是一个聚集索引结构,在使用 SELECT 语句查询时,查询执行计划可以是聚集索引扫描(Clustered Index Scan)或聚集索引查找(Clustered Index Seek)。

  对于聚集索引上的非聚集索引,则可能产生一个书签查找(Bookmark Lookup)。首先在非聚集索引上执行索引查找,在叶级找到一个指向聚集索引的指针,然后再去通过指针在聚集索引中搜索键值(Key Lookup),最终找到记录的其他列值。

3.2.2  “缺失”的索引

  提交一个查询时,查询优化器就分析和优化这个查询,然后选择满足查询的最高效方法,为查询创建一个优化的执行计划。即使要查询的表没有索引,查询优化器仍然会对表中的每一列进行基本的分布统计。

  因此,在缺少索引的情况下,查询优化器仍然可以确定索引的存在是否有利于查询。如果已经启用了AUTO_CREATE_STATISTICS选项,查询优化器会在确定创建索引可提高效率后,自动生成统计信息,随后的查询就可以用它来提高性能。

  查询优化器确定索引能提高性能,但索引却不存在,这时候查询优化器会创建一个“索引缺失”的状态。从sys.dm_db_missing_index_details视图可以看到某个可能需要建立的索引“缺失”的次数。

  索引缺失DMV会列出某些列的多种排列组合,为创建索引提供建议。列的每一个组合都会产生一个索引缺失,并生成一个条目。用于计算“有效因素”的查询语句如下:

SELECT * FROM
(SELECT user_seeks * avg_total_user_cost * (avg_user_impact * 0.01) AS
index_advantage, migs.* FROM sys.dm_db_missing_index_group_stats migs) AS
migs_adv
INNER JOIN sys.dm_db_missing_index_groups AS mig
ON migs_adv.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid
ON mig.index_handle = mid.index_handle
ORDER BY migs_adv.index_advantage

3.2.3  查看索引使用情况

  尽管替换了 DBCC SHOWCONTIG 的 sys.dm_db_index_physical_stats 功能强大,并有助于显示索引是否健全,但您还会经常遇到更为复杂的问题,如确定哪些索引可用于针对表而执行的查询。通常,数据库开发人员或管理员会针对他们认为在查询执行期间查询优化器会用到的表来生成索引。

  SQL Server 的先前版本中,很难知道这些索引是否确实在使用中。用户只有删除相应索引然后查看查询性能是否受到影响,或者是捕获查询的执行计划然后扫描索引的使用情况。现在有了一个新的 DMV(动态管理视图)sys.dm_db_index_usage_stats,这样,您很容易就可以了解到查询优化器使用索引的情况及针对表格执行查询的情况。您可以通过检查此视图来确定索引的有用性,这样您就可以删除查询优化器未在使用的任何索引。您不必再担心索引是否只是在浪费存储空间,或者对无用索引的维护会降低数据库性能。

  通过检查此 DMV 的输出结果可得出没有经过搜索和扫描的索引,这样就可确定自上次启动 SQL Server 以来某索引是否曾经使用过。不过,请记住,许多 DMV 和 DMF 不是永久有效,一旦 SQL Server 重启,它们就会将自身重置为零。在使用 DMV 或 DMF 确定索引的使用情况时,请将这一点考虑进去。某索引可能会自上次重新启动服务以来一直没有使用过,但在周末、月末或季度报表查询时却需要该索引。

3.2.4  查看索引操作的活动

  如果希望了解索引的操作活动,可以使用动态管理函数(DMF)sys.dm_db_index_operational_stats 来查看数据库中每个索引的 I/O、锁定、闭锁和访问方法活动,它们能够帮助您了解索引的使用情况以及诊断因过多的 I/O 活动或索引中存在“热点”而引起的索引锁定问题。

  使用此 DMF 的闭锁等待列可帮助确定 READ 和 WRITE 操作为获取对某索引资源的访问权限而花费的时间量。这可帮助您确定用于存储索引的磁盘子系统是否足以应付索引的 I/O 活动。它还可以指出索引的设计和使用情况是否引发了热点;热点是由于在索引的一个或多个页面中活动频繁从而导致争用这些页面中所包含的数据。这样的争用经常会导致对该区域尝试进行的 READ 或 WRITE 操作的大量阻塞。

  sys.dm_db_index_operational_stats 函数有4个参数,与sys.dm_db_index_physical_stats 的参数类似。前面2个参数分别是db ID和table ID,第3个为index ID(null则显示所有的索引),第4个为partition ID(null则显示所有的分区)。


SELECT page_latch_wait_count , page_latch_wait_in_ms ,

row_lock_wait_in_ms , page_lock_wait_in_ms , row_lock_count , page_lock_count , page_io_latch_wait_count , page_io_latch_wait_in_ms

FROM sys.dm_db_index_operational_stats (DB_ID(‘db01‘) ,

OBJECT_ID(‘table1‘) , NULL , NULL )

时间: 2024-10-13 00:20:16

3.2 “缺失”的索引的相关文章

SQLSERVER如何查看索引缺失

转自:http://www.cnblogs.com/lyhabc/archive/2013/02/10/2909761.html 当大家发现数据库查询性能很慢的时候,大家都会想到加索引来优化数据库查询性能, 但是面对一个复杂的SQL语句,找到一个优化的索引组合对人脑来讲,真的不是一件很简单的事. 好在SQLSERVER提供了两种“自动”功能,给你建议,该怎么调整索引 第一种是使用DMV 第二种是使用DTA (database engine tuning advisor) 数据库引擎优化顾问 这篇

SQL Server 索引优化 ——索引缺失

本文我们将重点给出动态视图法发现数据库中缺失的索引.对于索引的调整和新建将不在本文阐述范围,后续将陆续分享相关经验. sys.dm_db_missing_index_details 缺失索引明细,包括相等列,不等列以及包含列,执行如下脚本,并查看结果 USE WideWorldImporters;GOSELECT * FROM sys.dm_db_missing_index_details; 从结果可以看出,所有数据库中,缺失索引的表或索引视图都被列出来了.但是否需要把列出来的缺失索引都直接建上

SQL group by底层原理——本质是排序,可以利用索引事先排好序

转自:http://blog.csdn.net/caomiao2006/article/details/52140993 由于GROUP BY 实际上也同样会进行排序操作,而且与ORDER BY 相比,GROUP BY 主要只是多了排序之后的分组操作.当然,如果在分组的时候还使用了其他的一些聚合函数,那么还需要一些聚合函数的计算.所以,在GROUP BY 的实现过程中,与 ORDER BY 一样也可以利用到索引. 在MySQL 中,GROUP BY 的实现同样有多种(三种)方式,其中有两种方式会

为什么需要索引

索引 概述 索引设计是数据库设计中比较重要的一个环节,对数据库的性能其中至关重要的作用,但是索引的设计却又不是那么容易的事情,性能也不是那么轻易就获取到的,很多的技术人员因为不恰当的创建索引,最后使得其效果适得其反,可以说“成也索引,败也索引”.在我经历过的,众多的数据库性能问题案例中,80% 系统都存在索引不合理的问题. 为什么需要索引 数据在磁盘上是以块的形式存储的.为确保对磁盘操作的原子性,访问数据的时候会一并访问所有数据块.磁盘上的这些数据块与链表类似,即它们都包含一个数据段和一个指针,

MySQL优化GROUP BY-松散索引扫描与紧凑索引扫描

满足GROUP BY子句的最一般的方法是扫描整个表并创建一个新的临时表,表中每个组的所有行应为连续的,然后使用该临时表来找到组并应用累积函数(如果有).在某些情况中,MySQL能够做得更好,即通过索引访问而不用创建临时表. 为GROUP BY使用索引的最重要的前提条件是所有GROUP BY列引用同一索引的属性,并且索引按顺序保存其关键字.是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引.为该部分指定的条件,以及选择的累积函数. 由于GROUP BY 实际上也同样会进行排序操作,而

MongoDB中索引的创建和使用详解

索引通常能够极大的提高查询的效率.在系统中使用查询时,应该考虑建立相关的索引.在MongoDB中创建索引相对比较容易. mongodb中的索引在概念上和大多数关系型数据库如MySQL是一样的.当你在某种情况下需要在MySQL中建立索引,这样的情景同样适合于MongoDB. 基本操作 索引是一种数据结构,他搜集一个集合中文档特定字段的值.MongoDB的查询优化器能够使用这种数据结构来快速的对集合(collection)中的文档(collection)进行寻找和排序.准确来说,这些索引是通过B-T

MongoDB 索引

索引通常能够极大的提高查询的效率.在系统中使用查询时,应该考虑建立相关的索引.在MongoDB中创建索引相对比较容易. MongoDB中的索引在概念上和大多数关系型数据库如MySQL是一样的.当你在某种情况下需要在MySQL中建立索引,这样的情景同样适合于MongoDB. 基本操作 索引是一种数据结构,他搜集一个集合中文档特定字段的值.MongoDB的查询优化器能够使用这种数据结构来快速的对集合(collection)中的文档(collection)进行寻找和排序.准确来说,这些索引是通过B-T

SQL Server调优系列进阶篇(如何维护数据库索引)

原文:SQL Server调优系列进阶篇(如何维护数据库索引) 前言 上一篇我们研究了如何利用索引在数据库里面调优,简要的介绍了索引的原理,更重要的分析了如何选择索引以及索引的利弊项,有兴趣的可以点击查看. 本篇延续上一篇的内容,继续分析索引这块,侧重索引项的日常维护以及一些注意事项等. 闲言少叙,进入本篇的主题. 技术准备 数据库版本为SQL Server2012,前几篇文章用的是SQL Server2008RT,内容区别不大,利用微软的以前的案例库(Northwind)进行分析,部分内容也会

SQL Server 性能调优3 之索引(Index)的维护

SQL Server 性能调优3 之索引(Index)的维护 热度1 评论 16 作者:溪溪水草 前言 前一篇的文章介绍了通过建立索引来提高数据库的查询性能,这其实只是个开始.后续如果缺少适当的维护,你先前建立的索引甚至会成为拖累,成为数据库性能的下降的帮凶. 查找碎片 消除碎片可能是索引维护最常规的任务,微软官方给出的建议是当碎片等级为 5% - 30% 之间时采用 REORGANIZE 来“重整”索引,如果达到 30% 以上则使用 REBUILD 来“重建”索引.决定采用何种手段和操作时机可