clustered 和 non-clustered index 有什么区别？
【问题讨论】：
标签： sql-server indexing clustered-index non-clustered-index
聚集索引
非聚集索引
非聚集索引在检索数据时速度较慢，在检索数据时速度较快 插入和更新。
一个表可以有多个非聚集索引。
需要额外的空间来存储逻辑结构。
对磁盘上存储数据的顺序没有影响。
【讨论】：
优点：
聚集索引适用于范围（例如，从 my_table 中选择 *，其中 my_key 在 @min 和 @max 之间）
在某些情况下，如果您使用 orderby 语句，DBMS 将不必进行排序工作。
缺点：
聚集索引可能会减慢插入速度，因为如果新键不按顺序插入，则必须在放入记录时修改记录的物理布局。
【讨论】：
集群基本上意味着数据在表中的物理顺序。这就是为什么每张桌子只能有一个。
非集群意味着它“只是”一个逻辑顺序。
【讨论】：
除了这些差异之外，您还必须知道，当表是非聚集的（当表没有聚集索引时）数据文件是无序的并且它使用堆数据结构作为数据结构。
【讨论】：
// 抄自MSDN，非聚集索引的第二点在其他答案中没有明确提及。
集群
非集群
【讨论】：
【讨论】：
一个索引数据库有两个部分：一组物理记录，它们以任意顺序排列，一组索引标识读取记录的顺序，以产生按某种标准排序的结果。如果物理排列和索引之间没有关联，那么按顺序读取所有记录可能需要进行大量独立的单记录读取操作。因为一个数据库可能能够在比读取两个不连续记录的时间更短的时间内读取数十个连续记录，如果索引中连续的记录也连续存储在磁盘上，则性能可能会有所提高。指定索引是聚集的会导致数据库做出一些努力（不同的数据库在多少方面有所不同）来安排事情，以便索引中连续的记录组在磁盘上是连续的。
例如，如果要从一个空的非集群数据库开始并以随机顺序添加 10,000 条记录，则这些记录可能会按照添加顺序添加到末尾。按索引顺序读取数据库需要 10,000 次单记录读取。但是，如果要使用集群数据库，系统可能会在添加每条记录时检查之前的记录是否是自己存储的；如果发现是这种情况，它可能会将该记录与数据库末尾的新记录一起写入。然后，它可以查看移动记录所在的插槽之前的物理记录，并查看后面的记录是否由它自己存储。如果发现是这种情况，它可以将该记录移至该位置。使用这种方法会导致许多记录成对组合在一起，从而可能使顺序读取速度几乎翻倍。
实际上，集群数据库使用比这更复杂的算法。但是，需要注意的关键是在更新数据库所需的时间和按顺序读取数据库所需的时间之间进行权衡。维护集群数据库将显着增加以任何会影响排序顺序的方式添加、删除或更新记录所需的工作量。如果数据库被顺序读取的频率比更新的频率高得多，那么集群可能是一个巨大的胜利。如果它会经常更新但很少按顺序读取，则集群可能会消耗很大的性能，尤其是如果将项目添加到数据库的顺序与它们相对于集群索引的排序顺序无关。
【讨论】：
聚集索引
非聚集索引
当使用使用索引的字段选择数据时，这两种类型的索引都会提高性能，但将减慢更新和插入操作。
由于插入和更新速度较慢，因此应在通常为增量的字段（即 Id 或时间戳）上设置聚集索引。
SQL Server 通常仅在其选择性高于 95% 时才使用索引。
【讨论】：
聚集索引物理存储在表中。这意味着它们是最快的，每个表只能有一个聚集索引。
非聚集索引是单独存储的，您可以拥有任意数量的索引。
最好的选择是将聚集索引设置在最常用的唯一列上，通常是 PK。除非有非常令人信服的理由——想不出一个，但嘿，它可能就在那里——因为不这样做会出现。
【讨论】：
聚集索引本质上是索引列中数据的排序副本。
聚集索引的主要优势在于，当您的查询（查找）在索引中定位数据时，无需额外的 IO 即可检索该数据。
维护聚集索引的开销，尤其是在频繁更新的表中，可能会导致性能下降，因此最好创建非聚集索引。
【讨论】：
聚集索引对磁盘上的数据进行物理排序。这意味着索引不需要额外的数据，但只能有一个聚集索引（显然）。使用聚集索引访问数据是最快的。
所有其他索引必须是非聚集的。非聚集索引具有来自索引列的数据的副本，这些数据与指向实际数据行的指针一起保持有序（如果存在则指向聚集索引的指针）。这意味着通过非聚集索引访问数据必须经过额外的间接层。但是，如果您只选择索引列中可用的数据，您可以直接从重复的索引数据中取回数据（这就是为什么最好只选择您需要的列而不使用 *）
【讨论】：
聚集索引实际上描述了记录在磁盘上的物理存储顺序，因此您只能拥有一个。
非聚集索引定义的逻辑顺序与磁盘上的物理顺序不匹配。
【讨论】：