聚集索引和非聚集索引有什么区别？
聚集索引和非聚集索引有什么区别？
聚集索引
- 每桌只有一个
- 数据以索引顺序物理存储，比非聚簇更快
非聚集索引
- 每桌可以使用多次
- 插入和更新操作比聚集索引更快
当使用索引的字段select数据但是会减慢更新和插入操作时，这两种索引都会提高性能。
由于插入和更新速度较慢，聚簇索引应设置在通常为增量的字段上，即Id或Timestamp。
如果SQL Server的select性高于95％，通常只会使用索引。
聚簇索引物理sorting磁盘上的数据。 这意味着索引不需要额外的数据，但是只能有一个聚集索引（显然）。 使用聚集索引访问数据是最快的。
所有其他索引必须是非群集的。 非聚集索引具有索引列中的数据的副本，并与实际数据行（指向聚集索引的指针（如果有的话）的指针一起sorting）。 这意味着通过非聚集索引访问数据必须经过一个额外的间接层。 但是，如果只select索引列中可用的数据，则可以直接从重复的索引数据中获取数据（这就是为什么只select需要而不使用*的列）
聚簇索引在物理上存储在表上。 这意味着它们是最快的，每个表只能有一个聚簇索引。
非聚簇索引是分开存储的，您可以拥有任意数量的索引。
最好的select是在最常用的唯一列（通常是PK）上设置聚簇索引。 除非有一个非常有说服力的理由 – 不能想到一个单一的，但是嘿，它可能在外面 – 因为不这样做，你应该总是在表格中select一个好的聚集索引。
聚集索引
- 表格只能有一个聚集索引。
- 通常在主键上进行。
- 聚集索引的叶节点包含数据页面。
非聚集指数
- 一个表只能有249个非聚簇索引。
- 通常在任何键上。
- 非聚集索引的叶节点不包含数据页面。 相反，叶节点包含索引行。
聚集索引
- 表中只能有一个聚簇索引
- 对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物理存储在磁盘上的顺序，因此你只能有一个。
非聚簇索引定义与磁盘上的物理顺序不匹配的逻辑顺序。
