An indexed database has two parts: a set of physical records, which are arranged in some arbitrary order, and a set of indexes which identify the sequence in which records should be read to yield a result sorted by some criterion. If there is no correlation between the physical arrangement and the index, then reading out all the records in order may require making lots of independent single-record read operations. Because a database may be able to read dozens of consecutive records in less time than it would take to read two non-consecutive records, performance may be improved if records which are consecutive in the index are also stored consecutively on disk. Specifying that an index is clustered will cause the database to make some effort (different databases differ as to how much) to arrange things so that groups of records which are consecutive in the index will be consecutive on disk.

For example, if one were to start with an empty non-clustered database and add 10,000 records in random sequence, the records would likely be added at the end in the order they were added. Reading out the database in order by the index would require 10,000 one-record reads. If one were to use a clustered database, however, the system might check when adding each record whether the previous record was stored by itself; if it found that to be the case, it might write that record with the new one at the end of the database. It could then look at the physical record before the slots where the moved records used to reside and see if the record that followed that was stored by itself. If it found that to be the case, it could move that record to that spot. Using this sort of approach would cause many records to be grouped together in pairs, thus potentially nearly doubling sequential read speed.

In reality, clustered databases use more sophisticated algorithms than this. A key thing to note, though, is that there is a tradeoff between the time required to update the database and the time required to read it sequentially. Maintaining a clustered database will significantly increase the amount of work required to add, remove, or update records in any way that would affect the sorting sequence. If the database will be read sequentially much more often than it will be updated, clustering can be a big win. If it will be updated often but seldom read out in sequence, clustering can be a big performance drain, especially if the sequence in which items are added to the database is independent of their sort order with regard to the clustered index.

An indexed database has two parts: a set of physical records, which are arranged in some arbitrary order, and a set of indexes which identify the sequence in which records should be read to yield a result sorted by some criterion. If there is no correlation between the physical arrangement and the index, then reading out all the records in order may require making lots of independent single-record read operations. Because a database may be able to read dozens of consecutive records in less time than it would take to read two non-consecutive records, performance may be improved if records which are consecutive in the index are also stored consecutively on disk. Specifying that an index is clustered will cause the database to make some effort (different databases differ as to how much) to arrange things so that groups of records which are consecutive in the index will be consecutive on disk.

For example, if one were to start with an empty non-clustered database and add 10,000 records in random sequence, the records would likely be added at the end in the order they were added. Reading out the database in order by the index would require 10,000 one-record reads. If one were to use a clustered database, however, the system might check when adding each record whether the previous record was stored by itself; if it found that to be the case, it might write that record with the new one at the end of the database. It could then look at the physical record before the slots where the moved records used to reside and see if the record that followed that was stored by itself. If it found that to be the case, it could move that record to that spot. Using this sort of approach would cause many records to be grouped together in pairs, thus potentially nearly doubling sequential read speed.

In reality, clustered databases use more sophisticated algorithms than this. A key thing to note, though, is that there is a tradeoff between the time required to update the database and the time required to read it sequentially. Maintaining a clustered database will significantly increase the amount of work required to add, remove, or update records in any way that would affect the sorting sequence. If the database will be read sequentially much more often than it will be updated, clustering can be a big win. If it will be updated often but seldom read out in sequence, clustering can be a big performance drain, especially if the sequence in which items are added to the database is independent of their sort order with regard to the clustered index.

聚集索引

聚集索引检索更快，插入更慢 和更新。 一个表只能有一个聚集索引。 不需要额外空间来存储逻辑结构。 确定在磁盘上存储数据的顺序。

非聚簇索引

非聚集索引在检索数据时较慢，在检索数据时较快 插入和更新。 一个表可以有多个非聚集索引。 需要额外的空间来存储逻辑结构。 对磁盘上存储数据的顺序没有影响。

聚集索引

每张桌子只有一个 由于数据按索引顺序物理存储，因此读取速度比非集群更快

非聚类索引

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

当选择使用索引的字段的数据时，这两种类型的索引都将提高性能，但会降低更新和插入操作的速度。

由于插入和更新较慢，聚集索引应该设置在一个字段上，通常是增量的，即Id或时间戳。

SQL Server通常只使用选择性高于95%的索引。

聚集索引实际上描述了记录在磁盘上物理存储的顺序，因此只能有一个聚集索引。

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

聚集索引

一个表中只能有一个聚集索引 对记录进行排序，并根据顺序进行物理存储 数据检索比非聚类索引快 不需要额外的空间来存储逻辑结构

非聚类索引

一个表中可以有任意数量的非聚集索引 请勿影响物理秩序。为数据行创建逻辑顺序，并使用指向物理数据文件的指针 数据插入/更新比聚类索引快 使用额外空间存储逻辑结构

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