高效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 ,现在我们试图执行实际的语句验证我们的观点,看看能发现什么。
相关文档:
SQL 2005 的存储过程和触发器调试大法(原创)
www.chengchen.net 程晨
昨天晚上我找遍了互联网也没有发现关于SQL2005存储过程和触发器的调试方法,研究到凌晨2点多钟,终于找到方法了,不干独享,拿出来分享。如果要转载,请保留版权,谢谢!
&nbs ......
转自:http://hi.baidu.com/cszoo/blog/item/2439a5f517c19c2dbc31093c.html
(1)
SELECT
表名=case when a.colorder=1 then d.name else '' end,
表说明=case when a.colorder=1 then isnull(f.value,'') else '' end,
字段序号=a.colorder,
字段名=a.name,
标识=case when COLUMNPROPERTY( a.id,a.name,' ......
第一步, 在收缩前先查看日志的大小:
SELECT *
from sysfiles
WHERE name LIKE ' % LOG %'
GO
第二步, 把数据库的恢复模式设成”简单”:
ALTER DATABASE 库名 SET RECOVERY SIMPLE
GO
第三步, 运行checkpoint指令, 把dirty page写进数据库:
CHECKPOINT
GO
第四步, 截断日志:
BACKUP ......
作中数据库经常出错死锁,并且还要要求解决当前的死锁,问题多多;
参照CSDN,中国风(Roy)一篇死锁文章并改进了下;
/***********************************************************************************************************************
整理人:黑木崖上的蜗牛(lenolotus) 日期:2009.04.28
************ ......
今天做SQL 优化,查找执行计划时,执行计划,发现此执行计划与以往的计划有所区别;找录互联网,终于找一篇有关研究比较深入的文章;
原执行计划使用的是索引扫描,突然一下会使用索引覆盖技术,效率大增;
SELECT * 的真相:索引覆盖(index coverage)
SELECT *的效率很糟糕吗?当然,所有人都知道这一点,但是为什么 ......