聚集索引和非聚集索引有什么区别?

聚集索引和非聚集索引有什么区别?

聚集索引

  • 每桌只有一个
  • 数据以索引顺序物理存储,比非聚簇更快

非聚集索引

  • 每桌可以使用多次
  • 插入和更新操作比聚集索引更快

当使用索引的字段select数据但是会减慢更新和插入操作时,这两种索引都会提高性能。

由于插入和更新速度较慢,聚簇索引应设置在通常为增量的字段上,即Id或Timestamp。

如果SQL Server的select性高于95%,通常只会使用索引。

聚簇索引物理sorting磁盘上的数据。 这意味着索引不需要额外的数据,但是只能有一个聚集索引(显然)。 使用聚集索引访问数据是最快的。

所有其他索引必须是非群集的。 非聚集索引具有索引列中的数据的副本,并与实际数据行(指向聚集索引的指针(如果有的话)的指针一起sorting)。 这意味着通过非聚集索引访问数据必须经过一个额外的间接层。 但是,如果只select索引列中可用的数据,则可以直接从重复的索引数据中获取数据(这就是为什么只select需要而不使用*的列)

聚簇索引在物理上存储在表上。 这意味着它们是最快的,每个表只能有一个聚簇索引。

非聚簇索引是分开存储的,您可以拥有任意数量的索引。

最好的select是在最常用的唯一列(通常是PK)上设置聚簇索引。 除非有一个非常有说服力的理由 – 不能想到一个单一的,但是嘿,它可能在外面 – 因为不这样做,你应该总是在表格中select一个好的聚集索引。

聚集索引

  1. 表格只能有一个聚集索引。
  2. 通常在主键上进行。
  3. 聚集索引的叶节点包含数据页面。

非聚集指数

  1. 一个表只能有249个非聚簇索引。
  2. 通常在任何键上。
  3. 非聚集索引的叶节点不包含数据页面。 相反,叶节点包含索引行。

聚集索引

  • 表中只能有一个聚簇索引
  • 对logging进行sorting并根据订单进行物理存储
  • 数据检索比非聚集索引更快
  • 不需要额外的空间来存储逻辑结构

非聚集索引

  • 表中可以有任意数量的非聚集索引
  • 不要影响物理顺序。 为数据行创build逻辑顺序,并使用指向物理数据文件的指针
  • 数据插入/更新比聚集索引更快
  • 使用额外的空间来存储逻辑结构

除了这些差异,你必须知道,当表是非集群(当表没有聚集索引时)数据文件是无序的,它使用堆数据结构作为数据结构。

聚集基本上意味着数据在表格中是按照该物理顺序的。 这就是为什么每个表只能有一个。

非集群意味着它是“唯一”的逻辑顺序。

优点:

聚集索引对于范围非常有用(例如select * from my_table,其中my_key在@min和@max之间)

在某些情况下,如果使用orderby语句,DBMS将不必进行sorting。

缺点:

聚集索引会减慢插入速度,因为如果新键不是按顺序排列的,logging的物理布局必须被修改。

聚集索引本质上是索引列中数据的sorting副本。

聚集索引的主要优点是,当查询(seek)将数据定位到索引中时,不需要额外的IO来检索该数据。

维护聚簇索引(特别是在频繁更新的表中)的开销可能导致性能下降,因此可能最好创build非聚簇索引。

一个索引数据库有两个部分:一组物理logging,它们以某种任意的顺序排列,还有一组索引,用来标识logging应该被读取的顺序,以产生按照某种标准sorting的结果。 如果物理安排和索引之间没有关系,那么按顺序读出所有logging可能需要进行大量独立的单logging读取操作。 由于数据库可能能够以比读取两个不连续logging花费的时间更less的时间读取数十个连续的logging,所以如果索引中连续的logging也连续存储在磁盘上,性能可能得到改善。 指定一个索引是聚集的将导致数据库做一些努力(不同的数据库有多less不同)来安排事情,以便索引中连续的logging组在磁盘上是连续的。

例如,如果从一个空的非群集数据库开始,以随机顺序添加10,000条logging,那么logging可能会按照添加的顺序添加到最后。 按索引顺序读出数据库将需要10,000个单logging读取。 但是,如果要使用集群数据库,则系统可能会检查添加每条logging时,以前的logging是否自己存储; 如果发现这种情况,可能会在数据库的末尾用新的logging来logging该logging。 然后,它可以在移动的logging所在的位置之前查看物理logging,并查看后面logging是否被自己存储。 如果发现是这样的话,它可以把这个logging移到那个地方。 使用这种方法会导致许多logging被成对地分组在一起,因此可能几乎翻倍连续的读取速度。

实际上,群集数据库使用比这更复杂的algorithm。 但需要注意的一点是,在更新数据库所需的时间和顺序读取所需的时间之间有一个折衷。 维护一个集群数据库将会以任何会影响sorting顺序的方式显着增加添加,删除或更新logging所需的工作量。 如果数据库的读取顺序要比更新更频繁,那么集群就是一个重大胜利。 如果经常更新但很less按顺序读取,则聚集可能是一个很大的性能下降,尤其是如果将项添加到数据库的顺序与聚簇索引相关的sorting顺序无关。

聚簇索引实际上描述了logging物理存储在磁盘上的顺序,因此你只能有一个。

非聚簇索引定义与磁盘上的物理顺序不匹配的逻辑顺序。