SQL开发中容易忽视的一些小地方(四)

核心提示： 根据园友 perfectdesign的观点,order by 时,如果字段是聚集索引将会是最优的,这点我个人以及MSDN都同意,奇怪的是,上面的语句中,leave_date上即聚集索引,然后order by leave_date desc,然而也会产生5万多次的member表扫描,好像是o

根据园友 perfectdesign的观点,order by 时,如果字段是聚集索引将会是最优的,这点我个人以及MSDN都同意,奇怪的是,上面的语句中,leave_date上即聚集索引,然后order by leave_date desc,然而也会产生5万多次的member表扫描,好像是order by 索引字段,无论是聚集还是非聚集都会大量增加对member表的扫描.真是百思不得其解.下面是详细的ID情况:

(2000 row(s) affected)

Table 'member'. Scan count 52796, logical reads 234885, physical reads 0, read-ahead reads 3687, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

Table 'v_hotel'. Scan count 1, logical reads 3121, physical reads 0, read-ahead reads 28, lob logical reads 0, lob physical reads 0, lob read-ahead reads 0.

测试结论:这种情况足以说明对于order by 字段创建索引并不一定能发挥非聚集索引的优势,至于其中原因本人不才,目前并无答案,如大家有答案还望指教一二.数据库的调优虽然有一定的原则及准则,但这些所谓准则并一定全对.本人觉的都仅供参考,还是要按实际情况来分析.

下面贴下MSDN对于非聚集索引应用场合的说明,我觉的还是可能参考的:

在创建非聚集索引之前，应先了解访问数据的方式。考虑对具有以下属性的查询使用非聚集索引：

使用 JOIN 或 GROUP BY 子句。

应为联接和分组操作中所涉及的列创建多个非聚集索引，为任何外键列创建一个聚集索引。

不返回大型结果集的查询。

创建筛选索引以覆盖从大型表中返回定义完善的行子集的查询。

包含经常包含在查询的搜索条件（例如返回完全匹配的 WHERE 子句）中的列。

相关文章：

SQL开发中容易忽视的一些小地方

SQL开发中容易忽视的一些小地方(二)

SQL开发中容易忽视的一些小地方( 三)

SQL开发中容易忽视的一些小地方(四)

SQL开发中容易忽视的一些小地方(五)