高效SQL查询之索引（II）
上回我们说到评估一条语句执行效率主要看逻辑 IO （啥是逻辑 IO ，啥是物理 IO 见联机文档），这次我们继续。
我们先说说，返回多行结果时，为什么 SQLServer 有时会选择 index seek ，有时会选择 index scan 。
以 nonclustered index 为例说明。
像所有的索引 B 树一样，非聚集索引树也包括完全由索引数据组成的根节点和中间级节点；但是和聚集索引树不同的是，聚集索引树叶节点包含的是基础表的数据页（我们常说，表的物理存储顺序和聚集索引相同，就是这个原因）,非聚集索引树叶节点是索引页。 SQLServer 通过非聚集索引查找数据时，会通过这个非聚集索引键值去搜索聚集索引，进而检索基础表数据行。
假设有这样一张表，非聚集索引树深度为 2 ，一层根节点（ 1 个索引页），一层叶节点（ 4 个索引页）。聚集索引树深度为 3 ，一层根节点（ 1 个索引页），一层中间级节点（ 2 个索引页），一层叶节点（ 250 页，也就是基础表物理存储页）表的数据假设 1w 行。注：所有数据均为假设，只为说明原理。
我们首先，再强调一遍， SQLServer 获取数据，总是以页为单位，就算是只读取一行也会获取整张页 （见《写有效率的 SQL 查询（ I ）》）
现在有一条简单查询 ( 如： select * from tb where col2 = 99 ， col2 是 tb 表中的非聚集索引 ) ，假设会返回 100 行。
Ok ，我们来分析如果以 Index seek 来查找这 100 行会有多少 IO 。 index seek 每次都从索引树根节点开始查找，找到中间级节点（ 99 对应的索引行），然后从该节点行开始连续遍历所有 col2 为 99 的索引行。在遍历这些行时，每拿到一条，都会通过该条索引行中聚集索引键值去聚集索引树中 index seek ，然后从数据页中获取数据。在最坏的情况下， col2 为 99 对应的索引行跨越了全部 4 个叶级非聚集索引页（当然，这没啥可能性，举例而已，切勿深究）；每次通过聚集索引树进行 index seek ， IO 开销最坏情况下是一个根节点，一个中间级节点，一个数据页 , 一共要 seek100 次，开销 300 个逻辑 IO 。综上，通过 nonclustered index seek 总共开销是 305 个 IO 。
要知道，我们的基础表数据页一共才 250 页，这说明了啥？说明就算是我从头到尾扫描一遍表也比 noncustered index seek 快。这时， SQL2k5 会产生一个完完全全的 clustered index scan 执行计划来搞定表扫描。
好了，现在我们再来分析 select * from tb1 where col2 = 1 。假设它的结果集为 5 行。如果这时还是�
相关文档：
有时我们会像下面的情况一样，为主表的谋一条记录，在中间表(T_Stud_Course 表)中同时插入多条数据
T_Student 表
Stud_ID
Name
1
Tom
2
Jack
T_Course 表
Course_ID
Course
1
Chinese
2
English
T_Stud_Course 表
ID
Stud_ID
Course_ID
1
1
1
2
1
2
3
2
2
现在我们可以下面的存储过程� ......
针对 SQL Server 内正在执行的每个请求返回一行。sys.dm_exec_connections
、sys.dm_exec_sessions
和sys.dm_exec_requests
服务器范围动态管理视图映射到 sys.sysprocesses
系统视图（先前为系统表）。
注意：
若要执行在 SQL Server 以外的代码（例如，扩展存储过程和分 ......
我们先看 NestedLoop 和 MergeJoin 的算法（以下为引用，见 RicCC 的《 通往性能优化的天堂 - 地狱 JOIN 方法说明 》 ):
==================================
NestedLoop:
foreach rowA in tableA where tableA.col2=?
{
search rowsB from tableB where tableB.c ......
