sql server 索引阐述系列四 表的B-Tree组织

一.概述  

  说到B-tree组织,就是指索引,它可以提供了对数据的快速访问。索引使数据以一种特定的方式组织起来,使查询操作具有最佳性能。当数据表量变得越来越大,索引就变得十分明显,可以利用索引查找快速满足条件的数据行。某些情况还可以利用索引帮助对数据进行排序,组合,分组,筛选。

  一个B-tree,根是唯一的遍历的起点。中间页 层次数是根据表的行数以及索引行的大小而变化。索引中的底层节点称为叶节点。叶节点它容纳了一行或多行具有指定键值的记录,对于聚集或非聚集,叶节点都是按照键值的顺序组成,对于复合索引就是若干键值的组合。

  1.聚集索引

  在聚集索引的叶节点里不仅包含了索引键,还包含了数据页。也就是说数据本身也是聚集索引的一部分。聚集索引基于键值联系使表中的数据有序。决定哪个键值作为聚集键是重要因素,当遍历到叶级别时,可以获取数据本身,而不是简单地得到一个指向数据的指针(非聚集索引数据未覆盖)。聚集索引在 sys.partitions区中有一行,其中,索引使用每个分区的 index_id = 1,默认情况下,聚集索引是单个分区。如果聚集索引有四个分区,就有四个 B-tree 结构,每个分区中有一个 B-tree结构,关于分区在sql server 分区(上)中有讲到。由于数据页链只能按一种方式排序,因此表只有一个聚集索引,一般情况查询优化器非常倾向于采用聚集索引,因为可以直接在叶级别找到数据。  查询优化器也只需要在某一段范围的数据页,进行扫描。聚集索引结构按物理顺序存储不是磁盘上的顺序,聚集索引的排序顺序仅是表数据链在逻辑上有序的。

  2.非聚集索引

  非聚集索引与聚集索引有一个相似的 B -tree索引结构。不同的是,非聚集索引不影响数据行的顺序。什么意思呢,就是说非聚集索引,叶级别不包含全部的数据,只包含了键值以及,在每个叶节点中的索引行包含了一个书签(bookmark),书签在聚集索引里就是相应的数据行的聚集索引键,在堆里就是行标识符RID,该书签告诉sql server可以在哪里找到与索引键相应的数据行。
理解了非聚集索引叶节点不包含全部数据时,就知道非聚集索引的存在并不影响数据分页的组织,因此每张表上最多249个非聚集索引。
非聚集索引在 sys.partitions 区中有一行, 非聚集索引标识 index_id >1。默认情况下,一个非聚集索引一个分区。

二. 缺少索引与索引查找的区别

  在简单介绍了索引原理后,我们来直观感觉下索引在查询时的重要性。下面演示一个product表,表中的数据有12236142条,如果用户根据表中的型号(model)来搜索。下面来看看缺少索引(没有使用到索引),以及索引查找(就是应用到了索引功能)。二者的区别

  2.1 缺少索引的演示

--查询型号model 值STI5203 在全表中有三条
SELECT Model FROM dbo.Product WHERE Model=‘STI5203‘

图下告诉我们缺少索引,如果加了索引将提高性能99.94%, 该查询扫描计数5 (扫描了5个区),逻辑读取次数为69951次(一次一页),耗时954毫秒。
执行计划告诉我们是索引扫描也叫缺少索引,索引名是ixUpByMemberID,注意索引扫描不是索引查找,索引扫描是说把索引组织上的页全部扫描了一遍。

  再通过下图我们清楚知道,ixUpByMemberID有5个区。5个区加起来的data_pages总页数是69730。上图逻辑读取是69951。相当于把索引中的页全部扫描了一遍。也可说是把12236142条数据全扫描了一次。

  在锁的介绍中我们知道,锁越多,发生阻塞和死锁的几率就越大。
  通过下图,对于page资源来说,就有IS锁(意向共享锁)上1000个。IS锁与X排它锁又不兼容,此时多用户在修改,删除表中数据时,将会发生阻塞或死锁的影响。

    总结:如果在生产环境,面对大数据表,条件查询很频繁,又缺失索引,系统整体性能将会被拖垮。

  2.2 查询索引查找的演示

  用户根据model查询,缺少了一个索引,在给model建立索引后,再来看

--查询型号model 值STI5203 在全表中有三条
SELECT Model FROM dbo.Product WHERE Model=‘STI5203‘

  下图的执行计划告诉我们是索引查找,也就是索引使用上了,该索引名叫ix_mdoel. 扫描计数1 个区,逻辑读取次数为4次,耗时0毫秒.

  再来看下索引查找的锁状态,下图告诉我们,只有锁往了一个page资源。

  总结:在大表上,合理使用了索引查找后,不但查询响应时间变快了,而且没有了大量的锁,相应的在其它page页上的修改,删除应不会受到影响。

三. B-tree组织存储空间的影响

  我们知道了对于聚集索引,它的叶子层就是数据本身,但当一个表有多个非聚集索引时,就需要对数据库存储空间加倍来支持这些索引的存储,所以从占用存储空间来说,在建非聚集索引时需要好好规划。下面是来自生产环境的一个表,有聚集索引和四个非聚集索引,来看看索引存储空间
在index_id=1的聚集索引中占用的空间total_pages是1448806页,也就是表的数据本身。 而非聚集索引占用空间total_pages是2180034页, 非聚集索引占用空间比表数据本身大了1.5倍。

  

原文地址:https://www.cnblogs.com/MrHSR/p/9238470.html

时间: 2024-11-04 18:13:52

sql server 索引阐述系列四 表的B-Tree组织的相关文章

sql server 索引阐述系列三 表的堆组织

一.   概述 这一节来详细介绍堆组织,通过讲解堆的结构,堆与非聚集索引的关系,堆的应用场景,堆与聚集索引的存储空间占用,堆的页拆分现象,最后堆的使用建议 ,这几个维度来描述堆组织.在sqlserver里,表有二种组织方式,在表上没有创建聚集索引时,表就是堆组织, 有聚集索引就是B树组织.无论哪种组织方式,都可以在表上建多个非聚集索引.表的组织方式也称为HOBT. 之所以称为堆,是因为它的数据不按任何顺序进行组织,而是按分区组对数据进行组织. 在一个堆中.用于保存数据之间的关系的唯一结构是索引分

sql server 索引阐述系列五 索引参数与碎片

-- 创建聚集索引 create table [dbo].[pub_stocktest] add constraint [pk_pub_stocktest] primary key clustered ( [sid] asc )with (pad_index = off, statistics_norecompute = off, sort_in_tempdb = off, ignore_dup_key = off, online = off, allow_row_locks = on, all

SQL Server索引语法 <第四篇>

从CREATE开始 通过显式的CREATE INDEX命令 在创建约束时作为隐含的对象 随约束创建的隐含索引 当向表中添加如下两种约束之一时,就会创建隐含索引. 主键约束(聚集索引) 唯一约束(唯一索引) 一.CREATE INDEX语法 CREATE INDEX语句所做的事情与其听上去一样-用于在指定表或视图上基于声明的列创建索引: CREATE [UNIQUE] [CLUSTERED | NONCLUSTERED] INDEX <index name> ON <table or vi

SQL Server与Oracle对比学习:表的管理和组织

http://blog.csdn.net/weiwenhp/article/details/8088979 我们知道数据库,顾名思义.最重要的东东就是管理数据,而数据在系统中主要是保存在表(table)中,所以数据库差不多所有的机制和操作都是围绕着table在打转转了.表的重要性可想而知.在表在数据库是怎么保存起来,怎么去访问呢? Oralce中的表的管理机制 实际上数据库管理系统和文件系统很类似的.数据库中的所有信息最终也是保存在一个个实际的文件中. Oracle中的表都是最终保存在一个个后缀

SQL Server索引进阶:第一级,索引简介

By David Durant, 2014/11/05 (first published: 2011/02/17) 原文地址: Stairway to SQL Server Indexes: Level 1, Introduction to Indexes 本文是SQL Server索引进阶系列(Stairway to SQL Server Indexes)的一部分. 索引是数据库设计的基础,向开发者显示了使用数据库大量数据库设计者的意图.不幸的是,索引大部分时候是在出现性能问题的时候,才被事后

SQL Server索引进阶:第十级,索引内部结构

原文地址: Stairway to SQL Server Indexes: Level 10,Index Internal Structure 本文是SQL Server索引进阶系列(Stairway to SQL Server Indexes)的一部分. 在之前的级别中,我们从逻辑的角度介绍索引,集中于它们能为我们做什么.现在,是时候从物理的角度,并且检查一下索引的内部结构,从理解索引的内部结构,引导我们理解索引在上层做的工作.通过索引的结构,它是如何维护的,你可以理解在进行插入,更新,删除的

SQL Server索引进阶:第九级,读懂执行计划

原文地址: Stairway to SQL Server Indexes: Level 9,Reading Query Plans 本文是SQL Server索引进阶系列(Stairway to SQL Server Indexes)的一部分. 在这个系列中,我们经常会以特定的方式执行特定的查询.我们引用生成的执行计划来支持我们的论调.SQL Server管理器显示的预估的和实际的查询计划,可以帮助我们确定索引的好处,以及其中的缺陷.因此,本文的主要目的是给你一些关于执行计划的充分的理解: 验证

SQL Server调优系列玩转篇三(利用索引提示(Hint)引导语句最大优化运行)

前言 本篇继续玩转模块的内容,关于索引在SQL Server的位置无须多言,本篇将分析如何利用Hint引导语句充分利用索引进行运行,同样,还是希望扎实掌握前面一系列的内容,才进入本模块的内容分析. 闲言少叙,进入本篇的内容. 技术准备 数据库版本为SQL Server2012,利用微软的以前的案例库(Northwind)进行分析,部分内容也会应用微软的另一个案例库AdventureWorks. 相信了解SQL Server的朋友,对这两个库都不会太陌生. 一.并行Hint提示 (MAXDOP N

SQL Server调优系列进阶篇(如何索引调优)

前言 上一篇我们分析了数据库中的统计信息的作用,我们已经了解了数据库如何通过统计信息来掌控数据库中各个表的内容分布.不清楚的童鞋可以点击参考. 作为调优系列的文章,数据库的索引肯定是不能少的了,所以本篇我们就开始分析这块内容,关于索引的基础知识就不打算深入分析了,网上一搜一片片的,本篇更侧重的是一些实战项内容展示,希望通过本篇文章各位看官能在真正的场景中找到合适的解决方法足以. 对于索引的使用,我希望的是遇到问题找到合适的解决方法就可以,切勿乱用!!! 本篇在分析出索引的优越性的同时也将负面影响