索引初探(二)

在SqlServer中分为两种索引,一是聚集索引;一是费聚集索引。下面我就分别对两种索引进行介绍并分析其区别和各自的特点。

1.聚集索引

之前看过一个比方,我觉得非常恰当这里也用这个例子来说明两种索引。我们的字典本身就像是一个聚集索引,我们根据拼音查找目录,然后直接可以找到查询字的页,而字典正文就是按照拼音的顺序进行的排序。从中我们不难总结聚集索引的特点:

  • 物理排序与逻辑排序顺序一致。
  • 每个表的此种排序只有一种。

如图:

    • 表中的全部数据都保存在B树中的叶层(leaf level)中,其他层只是起到一个索引的作用,并不包含任何数据。叶层是一个双向链表结构,并按照聚集索引的主键的逻辑顺序排列。因此逻辑顺序是用指针来维护。
    • 举例说明建立聚集索引的效果:
    • 上图没有建立聚焦索引的表根据时间段进行查询,结果逻辑读取了4080次,而同样对该时间段进行查询,建立索引后,逻辑读取锐减至1792次。可见聚集索引能大大减少io消耗,对于大规模数据的读取的性能提升是显而易见的。同时我们在对比数据的排序
    • 如图所示,在添加聚集索引前,数据以堆的形式按照先后顺序排列,增加聚集索引后,按照索引字段进行了逻辑排序。

接下来我们简单讨论一下:

1)聚集索引与插入操作

最简单的情况下,插入操作根据索引找到对应的数据页,然后通过挪动已有的记录为新数据腾出空间,最后插入数据。

如果数据页已满,则需要拆分数据页(页拆分是一种耗费资源的操作,一般数据库系统中会有相应的机制要尽量减少页拆分的次数,通常是通过为每页预留空间来实现):
    在该使用的数据段(extent)上分配新的数据页,如果数据段已满,则需要分配新段。
    调整索引指针,这需要将相应的索引页读入内存并加锁。
    大约有一半的数据行被归入新的数据页中。
2)聚集索引与删除操作

删除行将导致其下方的数据行向上移动以填充删除记录造成的空白。

如果删除的行是该数据页中的最后一行,那么该数据页将被回收,相应的索引页中的记录将被删除。如果回收的数据页位于跟该表的其它数据页相同的段上,那么它可能在随后的时间内被利用。如果该数据页是该段的唯一一个数据页,则该段也被回收。

对于数据的删除操作,可能导致索引页中仅有一条记录,这时,该记录可能会被移至邻近的索引页中,原索引页将被回收,即所谓的“索引合并”。

  • 2.非聚集索引
  • 非聚集索引也是以B树组织的。和聚集索引的区别就在于它的叶层并不包含所有的数据。在默认情况下它只包含了键列的数据,并包含了一个行定位符(row locator)。这个行定位符的具体内容取决于它建立在以堆形式的表还是以B树组织的表,换句话说也就是这张表是否建立了聚集索引会影响到非聚集索引的行定位符。如果是建立了聚集索引,那么这个行定位符就是一个聚集键,我们通过这个聚集键再次查找聚集索引上的数据。
  • 如图:
  • 总结
  • 这我们基本了解了聚集索引和非聚集索引,不难看出聚集索引是提高查询性能的利器。索引有助于提高检索性能,但过多或不当的索引也会导致系统低效。因为用户在表中每加进一个索引,数据库就要做更多的工作。过多的索引甚至会导致索引碎片。 比如当插入索引是就会引发一些列的操作从而影响系统性能,当然鱼和熊掌不能兼得,还得根据实际情况客观分析来建立合适的索引体系。下一节将专门展开介绍非聚焦索引。(写的太随笔,周末有事也是简单先写一点,不好意思了)
时间: 2024-08-08 09:41:16

索引初探(二)的相关文章

高性能索引-高性能索引策略二

1.覆盖索引 索引是一种查找数据的高效方式,如果MySQL可以使用索引来直接获取列的数据,这样就不再需要读取数据行.如果一个索引包含所有需要查询的字段的值,就称之为"覆盖索引".覆盖索引具有以下好处: 索引条目通常远小于数据行大小,所以如果只需要读取索引,就会极大的减少数据的访问. 索引是按列值顺序存储的,所以对I/O密集型的范围查询会比随机从磁盘读取每一行数据的I/O要少的多. 一些存储引擎如MyISAM在内存只会缓存索引. 由于InnoDB的聚族索引,覆盖索引对InnoDB非常有用

【IOS】IOS开发问题解决方法索引(二)

IOS开发问题解决方法索引(二) 1       不使用ARC编译,-fno-objc-arc ios5 选择了ARC但是不使用ARC编译,-fno-objc-arc http://leobluewing.iteye.com/blog/1384797 http://blog.cnrainbird.com/index.php/2012/03/13/object-c_kai_fa_zhong_hun_he_shi_yong_huo_bu_shi_yong_arc/ 2       SIGABRT错误

EF6.0+APS.NET MVC5.0项目初探二(类库引用关系及说明)

接着上一篇(EF6.0+APS.NET MVC5.0项目初探一(界面展示),说说我搭建项目的一点心得. 第一步:我喜欢先建一个空的解决方案,只是个人喜好,不喜勿喷,呵呵. 如图: 第二步:添加项目所需要的类库: 如图: 第三步:添加类库引用 UI.Manage->BusinessLogic.BLL,Domain.Entity,Domain.ViewModel,Infrastructure.Common,UI.HtmlHelper BusinessLogic.BLL->Domain.Entity

Lucene.Net 2.3.1开发介绍 —— 三、索引(二)

原文:Lucene.Net 2.3.1开发介绍 -- 三.索引(二) 2.索引中用到的核心类 在Lucene.Net索引开发中,用到的类不多,这些类是索引过程的核心类.其中Analyzer是索引建立的基础,Directory是索引建立中或者建立好存储的介质,Document和Field类是逻辑结构的核心,IndexWriter是操作的核心.其他类的使用都被隐藏掉了,这也是为什么Lucene.Net使用这么方便的原因. 2.1 Analyzer 前面已经对Analyzer进行了很详细的讲解,Ana

数据库索引(二)聚集/非聚集索引,索引和锁

聚集索引(InnoDB,使用B+Tree作为索引结构) 在一个结构中保存了b-tree索引和数据行:按照主键的顺序存储在叶子页上: 主键索引:叶节点存储(主键数据:所有剩余列数据) 二级索引(非聚簇索引):叶节点存储(索引列数据:主键数据) 非叶节点只存储 索引列 优点: 可以把相关数据保存在一起,如根据用户id聚集电子邮箱信息,只需要读取少数的数据页就能获取某个id用户的全部邮件: 数据访问更快,将索引和数据保存在同一个b-tree中: 使用覆盖索引扫描的查询可以直接使用页节点中的主键值: 缺

MySQL索引(二)B+树在磁盘中的存储

MySQL索引(二)B+树在磁盘中的存储 回顾 ? 上一篇文章<MySQL索引为什么要用B+树>讲了MySQL为什么选择用B+树来作为底层存储结构,提了两个知识点: B+树索引并不能直接找到行,只是找到行所在的页,通过把整页读入内存,再在内存中查找. 索引的B+树高度一般为2-4层,查找记录时最多只需要2-4次IO. 为进一步知其所以然,今天来聊聊B+树索引在物理磁盘上是怎么设计存储的. 一.理解为什么要减少磁盘IO次数 众所周知,MySQL的数据实际是存储在文件中,而磁盘IO的查找速度是要远

R简单算术操作符&lt;函数和+-*/&gt;,缺失值,正则向量,向量运算&lt;索引&gt;(二)

赋值操作 x <- c(1,2,3); x = c(1,2,3); c(1,2,3) -> x; assign("x", c(1,2,3)); 这四种形式在大部分时候都能达到一致的效果.推荐使用第一种 1:向量的定义 一串有序数值构成的数值向量(vector) ,创建一个向量我们使用c(num1,num2,num3); 在 R 环境里面,单个的数值也是被看作长度为1的向量. 1.1 向量的基本运算 在算术表达式中使用向量将会对该向量的每一个元素都进行同样算术运算.出现 在同

索引初探(三)

由于前一篇写的有点匆忙很多地方不是很简单,这一片再描述一些概念和细节. 首先,我们都知道在数据库中的存储分为两种结构,一是堆:二是B树.堆的数据是没有排序也就没有结构性可言,我们可以简单理解为没有索引的表数据就是以堆的形式存在的.与之相对的,索引都是B树的形式存储,这样的话索引中数据是有序排列的. 其次,索引的结构上篇也是讲了,我们这里再根据非聚集索引的结构来对比一下聚集索引. 如图(官方提供的非聚集索引的结构图): 我们不难看出,上面红色标注的是非聚集索引,下面是聚集索引或者堆.由这个图来分析

2. C#数据结构与算法 -- 查找算法(顺序查找,哈希查找,二分查找(折半),索引,二叉)

1. 顺序查找算法 ===================================================== 算法思想简单描述: 最突出的查找类型就是从记录集的开始处顺次遍历每条记录,直到找到所要的记录或者是 到达数据集的末尾.这就是所谓的顺序查找.顺序查找(也被称为线性查找)是非常容易实现 的.从数组的起始处开始,把每个访问到的数组元素依次和所要查找的数值进行比较.如果找 到匹配的数据项,就结束查找操作.如果遍历到数组的末尾仍没有产生匹配,那么就说明此数 值不在数组内. ==