Thought Persistence

在blog的修改中，我对几个表的主键进行了删除，使用唯一索引代替，从而把宝贵的聚集索引机会让给其它更需要的索引。

聚集索引的好处就是可以让数据按照此索引的顺序进行物理位置存放，用blog_Comment表来说明，此表有
comm_id
comm_logid
comm_author
comm_posttime等字段

comm_id是自增ID，唯一性索引，如果让它做主键的话，那么聚集索引也默认是它了。但是我们知道comm_id的增长顺序和postime是一致的，可是我们在批量取数据时，是否会用这样一个顺序区间来过滤呢？

比如说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的查询。

也许随着数据量的增长，情况会有不同，这个以后再看情况调整了。