如何设置聚集索引(Cluster Index)

聚集索引的好处就是可以让数据按照此索引的顺序进行物理位置存放，用blog_Comment表来说明，此表有comm_idcomm_logidcomm_authorcomm_posttime等字段比如说posttime between DATE1 and DATE2,OK这样的话聚集索引利用到了，因为这个区间段的数据是非常亲密地靠在一起的，可以用最少的I/O开销取得所需的结果集。可是我们知道，更多的时候我们是在显示一个article时然后读取它的所有comments，这时，过滤条件就成了comm_logid = ID了，如果聚集索引被comm_id心安理得地占用的话，那么很可能我们这批comments需要多个数据页才能得到，这样的话，就大大地增加了时间，因为I/O的开销比CPU在内存上的数据查找排序都是要高一个数据级的。但是聚集索引的改变同样会给其它的查询带来负面影响，比如说comm_id = ID的查询，在原来只需要在PK_blog_Comment_comm_id的聚集索引上查找记录，然后得到的指针指向就是实际数据块的存放位置了，但是现在，在此非聚集的唯一索引上查找得到的指针是指向IX_blog_Comment_comm_logid的的位置，所以需要多一次的Bookmark Lookup才能取得所需数据。其实使用的方法很简单，当你需要频繁地取得批量数据时，把聚集索引放在最有可能定位区间的字段上。另外blog_Article的聚集索引我放在posttime上了，因为经常要对此字段进行order by的查询，虽然logid和posttime的排序方向是一样的，但是我这样可能通过cluster index的lookup 节省一个order by的时间，不过到底孰优孰劣我还不敢下结论。其它的blog_Archive,blog_Category的聚集索引都在authorid上，因为这个都是对于authorid = ID的查询。也许随着数据量的增长，情况会有不同，这个以后再看情况调整了。

将上图中的

select * from CGNPCZJYHHD where ZJYHHD_JYRQ>='20171101'

修改为：

select ZJYHHD_JYRQ from CGNPCZJYHHD where ZJYHHD_JYRQ>='20171101'

再观察下有什么不同。

就能理解，SQL索引里需要有包含列这个概念了

在 Microsoft SQL Server 数据库中，您可以创建聚集索引。在聚集索引中，表中行的物理顺序与索引键值的逻辑（索引）顺序相同。一个表只能包含一个聚集索引。

创建聚集索引

在对象资源管理器中，右键单击要为其创建聚集索引的表，然后单击“设计”。

此时，将在表设计器中打开该表。

在表设计器菜单上，单击“索引/键”。

在“索引/键”对话框中，单击“添加”。

从“选定的主/唯一键或索引”列表中选择新创建的索引。

在网格中，选择“创建为聚集的”，然后从该属性右侧的下拉列表中选择“是”。

保存表时将在数据库中创建该索引。

---