高效SQL查询之索引（III）
先说说这些误区。所谓“误区”，有一些是新手很容易犯的错误或者很容易忽略的问题，另外一些，则是像“耗子吃了盐会变成蝙蝠”一样，让我们从小就认为是正确的事情。如下：
1、 表上不管用得着用不着，都加个聚集索引。
我们知道，表以两种方式组织物理存储：有聚集索引的“聚集表”；没有聚集索引的“堆”。在聚集表中，数据行按照聚集索引的顺序存储（这也是为啥一张表最多只能有一个聚集索引的原因）；堆中，数据行的存储可以认为是不确定的。
在偶《写有效率的 SQL 查询（ II ）》中曾经介绍过 DB 引擎如何在聚集表中通过非聚集索引查找目标数据：从非聚集索引树根开始 seek ，查找到目标索引行，然后通过索引行上存储的聚集索引键值，爬聚集索引树，并最终通过聚集索引行上的指针拿到目标数据。
但是堆上的非聚集索引存储的不是聚集索引键值，它存储的是指向目标行的指针。也就是说，如果在同样的表是堆，通过非聚集索引 seek 数据将省掉爬聚集索引树的损耗，而可以直接通过非聚集索引行上的行指针直接拿到目标数据。也就是说，在某些情况下，使用堆可以提高系统效率。
这个“某些情况”，就是你的需求，你的系统行为。一般情况下，所有人对要在什么样的字段上创建聚集索引都非常了解；但是不是所有的人都对应该在什么样的系统行为下，不创建聚集索引了解。假设你的表中有字段 col1, col2,col3,col4 等等， col1 、 col2 的分布密度很低。你观察了系统行为，发现一半的查询是 XXXX where col1 = YYYY ，另一半的查询是 XXXX where col2 = YYYY 。这种情况下，使用堆就是更好的选择。
2、 primary key 就是聚集索引。
primary key 上是得有索引，但是这个索引可不见得一定得是聚集索引。尽管语句
create table testPK
(
id int identity ( 1, 1) primary key ,
fname varchar ( 64)
)
会在 id 列上创建聚集索引。当然，一般主键都是聚集索引，但也仅仅是“一般”而已。个人感觉，聚集索引的唯一目标就是数据检索，它应该建在什么字段上，完全由系统行为决定。“一般主键都是聚集索引”也仅仅是因为多数情况下， primary key 字段上建所有更有益于效率而已。
create table testPK
(
相关文档：
通常，你需要获得当前日期和计算一些其他的日期，例如，你的程序可能需要判断一个月的第一天或者最后一天。你们大部分人大概都知道怎样把日期进行分割（年、月、日等），然后仅仅用分割出来的年、月、日等放在几个函数中计算出自己所需要的日期！在这篇文章里，我将告诉你如何使用DATEADD和DATEDIFF函数来计算出在你的程序� ......
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！
（1） 选择最有效率的表名顺序(只在基于规则的优化器中有效)：
ORACLE 的解析器按照从右到左的顺序处理from子句中的表名，from子句中写在最后的表(基础表 driving table)将被最先处理，在from� ......
还是一转帖，总结的不错，大家借鉴。
原网址：
http://database.ctocio.com.cn/222/9068222.shtml
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出 ......
大型系统的生产环境，一般情况下，我们评价一条查询是否有效率，更多的是关注逻辑 IO( 至于为什么，回头补一篇 ) 。我们常说，“要建彪悍的索引”、“要写高效的 SQL ”，其实最终目的就是在相同结果集情况下，尽可能减少逻辑 IO 。
1.1 where 条件的列上都得有统计信息。
......
上回我们说到评估一条语句执行效率主要看逻辑 IO （啥是逻辑 IO ，啥是物理 IO 见联机文档），这次我们继续。
我们先说说，返回多行结果时，为什么 SQLServer 有时会选择 index seek ，有时会选择 index scan 。
以 nonclustered index 为例说明。
像所有的索引 B 树一样，非聚集索引树也包括完全由索引数据组成的根� ......
