今天看到篇文章,里面有个表格:
-----------------------------------------------------
| 动作描述 | 使用聚集索引 | 使用非聚集索引 |
| 列经常被分组排序 | 应 | 应 |
| 返回某范围内的数据 | 应 | 不应 |
| 一个或极少不同值 | 不应 | 不应 |
| 小数目的不同值 | 应 | 不应 |
| 大数目的不同值 | 不应 | 应 |
| 频繁更新的列 | 不应 | 应 |
| 外键列 | 应 | 应 |
| 主键列 | 应 | 应 |
| 频繁修改索引列 | 不应 | 应 |
———————————————————————————但是看到当“小数目的不同值”应该使用聚集索引,而“大数目的不同值”应该使用非聚集索引的时候,有些迷惑。文中还特意指出,自增长的ID类型的字段,做主键可以,但是做聚集索引,意义不大。我想,这应该是验证ID类型字段属于“大数目的不同值”,应该使用非聚集索引吧。主键是唯一索引,既然是唯一的,数目肯定大。比如有100万条记录,主键的可能值肯定就有100W个(不考虑复合主键),既然数目大,按照这个逻辑,主键应该使用非聚集索引。但是主键默认都是聚集索引,这是不是有些矛盾?原文见:http://www.vckbase.com/document/viewdoc/?id=1307
-----------------------------------------------------
| 动作描述 | 使用聚集索引 | 使用非聚集索引 |
| 列经常被分组排序 | 应 | 应 |
| 返回某范围内的数据 | 应 | 不应 |
| 一个或极少不同值 | 不应 | 不应 |
| 小数目的不同值 | 应 | 不应 |
| 大数目的不同值 | 不应 | 应 |
| 频繁更新的列 | 不应 | 应 |
| 外键列 | 应 | 应 |
| 主键列 | 应 | 应 |
| 频繁修改索引列 | 不应 | 应 |
———————————————————————————但是看到当“小数目的不同值”应该使用聚集索引,而“大数目的不同值”应该使用非聚集索引的时候,有些迷惑。文中还特意指出,自增长的ID类型的字段,做主键可以,但是做聚集索引,意义不大。我想,这应该是验证ID类型字段属于“大数目的不同值”,应该使用非聚集索引吧。主键是唯一索引,既然是唯一的,数目肯定大。比如有100万条记录,主键的可能值肯定就有100W个(不考虑复合主键),既然数目大,按照这个逻辑,主键应该使用非聚集索引。但是主键默认都是聚集索引,这是不是有些矛盾?原文见:http://www.vckbase.com/document/viewdoc/?id=1307
对于小数据量来说,比如几百条,使用聚集/非聚集影响都不大。
但是对于大数据量的数据来说,比如亿级数据量,就需要做详细的考虑了。
————————————————————————
我的理解是:在SQLSERVER中如果对“大数目的不同值”使用聚集索引,因为聚集索引是对键物理位置的索引,由于大数目的不同值导致SQLSERVER需要在insert数据的时候不断调整物理存储位置,这样肯定导致性能下降。
------------------------------
明白了但是对于大数据量的数据来说,比如亿级数据量,就需要做详细的考虑了。
------------------------------
是否在某种情况,将主键设置为聚集索引,比作为非聚集索引有明显的大的优势呢?不然为什么要默认为聚集索引呢?
在小的数据量下,聚集与非聚集差别不大,但是大的数据量下,由于数据量大,主键的不同值也大,那么是否非聚集更适合主键呢?这么来看,如果真的考虑默认值的话,不是将主键默认为非聚集索引更适合吗?
因为对于一张数据表来说,一般情况下都会涉及对其的增删改操作,其中,删改都会通过主键作为条件找到相应表记录,此时理论上,聚集索引的性能优于非聚集索引。
lz可以去看看聚集索引、非聚集索引相关的原理图。