高效SQL查询之索引（VI)
我们先看 NestedLoop 和 MergeJoin 的算法（以下为引用，见 RicCC 的《 通往性能优化的天堂 - 地狱 JOIN 方法说明 》 ):
==================================
NestedLoop:
foreach rowA in tableA where tableA.col2=?
{
search rowsB from tableB where tableB.col1=rowA.col1 and tableB.col2=? ;
if(rowsB.Count<=0)
discard rowA ;
else
output rowA and rowsB ;
}
MergeJoin:
两个表都按照关联字段排序好之后， merge join 操作从每个表取一条记录开始匹配，如果符合关联条件，则放入结果集中；否则，将关联字段值较小的记录抛弃，从这条记录对应的表中取下一条记录继续进行匹配，直到整个循环结束。
==================================
我们通过最简单的情况来计算 NestedLoop 和 MergeJoin 的消耗：
两张表 A 、 B ，分别有 m 、 n 行数据（ m < n ），占用基础表物理存储空间分别为 a 、 b 页，聚集索引树非叶节点都是两层（一层根节点，一层中间级节点）， A 、 B 的聚集索引建在 A.col1 、 B.col1 上。一条查询语句：
select A.col1, B.col2 from A inner join B where A.col1 = B.col1 。
执行 NestedLoop 操作 ：
A 作为 outer input ， B 作为 inner input 时： A 带来的 IO 为 a ；每次通过 clustered index seek 执行内部循环，花费 3( 一个根节点、一个中间集结点、一个叶节点。当然也可能直接从根节点就拿到要的数据，我们只考虑最坏的情况），这样执行整个嵌套循环过程消耗 IO 为 a + 3*m 。如果 B 作为 inner input ， A 作为 outer input 分析类似。
执行 MergeJoin :
MergeJoin 要把 A 、 B 两张表做个 Scan ，然后进行 Merge 操作。所以 A 、 B 分别带来 IO 为 a + b 就是总的逻辑 IO 开销。
从上述分析来看，若 a + 3*m << a + b ，即 3*m << b ，那么 NestedLoop 性能是极佳的。当然，我们比较 A 表的行和 B 表所占数据页大小看上去有点夸张，但是量化分析确实如此。在这里，我们没有计算 NestedLoop 和 MergeJoin 本身的 cpu 计算开销，特别是后者，这部分并不能完全忽略，但是也来得有限。
OK ，现在我们试图执行实际的语句验证
相关文档：
系统环境：Windows 7
软件环境：Visual C++ 2008 SP1 +SQL Server 2005
本次目的：编写一个航空管理系统
这是数据库课程设计的成果，虽然成绩不佳，但是作为我用VC++ 以来编写的最大程序还是传到网上，以供参考。用VC++ 做数据库设计并不容易，但也不是不可能。以下是我的程序界面，后面 ......
有时， 为了让应用程序运行得更快，所做的全部工作就是在这里或那里做一些很小调整。啊，但关键在于确定如何进行调整！迟早您会遇到这种情况：应用程序中的 SQL 查询不能按照您想要的方式进行响应。它要么不返回数据，要么耗费的时间长得出奇。如果它降低了报告或您的企业应用程序的速度，用户必须等待的时间过长，他们就会 ......
【IT168 技术文档】
介绍
SQL SERVER2005提供了在.NET中自定义函数、存储过程、聚合、触发器以及类型的功能。于是，我们可以在数据库的函数、存储过程或类型整合.NET对象方法等。在之前的一篇文章，我们演示了如何将正则表达式功能整合到SQL CLR中。在本文中，还是演示这种整合，但是这次是从SQL CLR� ......
上回我们说到评估一条语句执行效率主要看逻辑 IO （啥是逻辑 IO ，啥是物理 IO 见联机文档），这次我们继续。
我们先说说，返回多行结果时，为什么 SQLServer 有时会选择 index seek ，有时会选择 index scan 。
以 nonclustered index 为例说明。
像所有的索引 B 树一样，非聚集索引树也包括完全由索引数据组成的根� ......
