高效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 行。如果这时还是�
相关文档：
sql 2005表的复制有两种：一种就是把整个表复制过去，就好像复制文件并且重命名。别外一种就是把表的内容复制过出.
select * into newtable form oldtable;把oldtabel复制到newtable且newtable不存在,否则出错.;
insert into newtable select * from oldtable把oldtable的内容插入到newtable, newtable一定要存在, ......
定义和用法
DATEDIFF() 函数返回两个日期之间的天数。
语法
DATEDIFF(datepart,startdate,enddate)
startdate 和 enddate 参数是合法的日期表达式。
datepart 参数可以是下列的值：
datepart
缩写
年
yy, yyyy
季度
qq, q
月
mm, m
年中的日
dy, y
日
dd, d
周
wk, ww
星期
dw, w
小时
h ......
作中数据库经常出错死锁，并且还要要求解决当前的死锁，问题多多；
参照CSDN，中国风(Roy)一篇死锁文章并改进了下；
/***********************************************************************************************************************
整理人：黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************ ......
先站在应用程序的角度说说它们的不同。
1、 直接拼 SQL
就像大家了解的那样，直接拼 SQL 带来了 SQL 注入攻击，带来了拼时些许的性能损失，但是拼不用添加 SqlParameter ，会少写很多代码——很多人喜欢直接拼，也许就因为这点。这种做法会把你拼好的 SQL 原样直接发送到 DB 服务器去执行。（注意类似 &rdquo ......
我们先看 NestedLoop 和 MergeJoin 的算法（以下为引用，见 RicCC 的《 通往性能优化的天堂 - 地狱 JOIN 方法说明 》 ):
==================================
NestedLoop:
foreach rowA in tableA where tableA.col2=?
{
search rowsB from tableB where tableB.c ......
