高效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 ，现在我们试图执行实际的语句验证我们的观点，看看能发现什么。
相关文档：
--合并行，并返回合并的值
Create proc [dbo].[proUniteRow]
@tab varchar(30), --表名
@col varchar(30), --合并的列名
@where varchar(2000), &nbs ......
一、 PL/SQL语言简介
(本讲义之所有程序均调式通过)
首先我们看一个简单之例子,下面这个例子是统计从1至100的总和.
declare
i number:=0; /*声明变量井给初值*/
t number:=1;
error_message exception; /*声明一个出错处理*/
begin
......
有时我们会像下面的情况一样，为主表的谋一条记录，在中间表(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
现在我们可以下面的存储过程� ......
今天在配置数据库发布和分发时总是报出现 18483 错误
提示说：错误 18483:未能连接到服务器 "XXX"，因为 'distributor_admin'未在该服务器上定义为远程登陆。
我的发布和分发是同一个服务器，"XXX" 为我的机器名，分发数据库是默认的名称，而我在另外一台机器上做时就正常。
1、设置共享复制目录:
......
