关系型数据库的工做原理(四)

查询优化：

    现代数据库都使用一种基于成本优化（参见第一部分）的方式进行优化查询，这种方式的思路是给每种基本运算设定一个成本，而后采用某种运算顺序总成本最小的方式进行查询，获得最优的结果。

    为简化理解，对数据库的查询重点放在查询时间复杂度上，而不考虑CPU消耗，内存占用与磁盘I/O，且相比与CPU消耗，数据库瓶颈也更多在磁盘I/O。

    索引

    B+树、bitmap index等都是常见的索引实现方式，不一样的索引实现有不一样的内存消耗、I/O以及CPU占用。一些现代数据库还能够建立临时索引。

    获取（数据）方式：

    在进行链接查询操做以前，须要先获取数据，如下是常见的获取方式（数据获取的关键在磁盘I/O，故在衡量获取方式时，考察量也应在此）。

    全扫描

    全扫描（full scan or scan），即扫描整个表或者全部索引，全表扫描的磁盘I/O明显高于全索引扫描。

    范围扫描

    AGE字段有索引，当sql使用谓词where age < 20 and age >20时(between and会在上面查询解析阶段改为<和>)，便会使用范围索引。参见第一部分知，范围扫描的复杂度为log(N)+M，N是索引中的数据量，M是搜索范围内行数，可见范围扫描比全索引扫描有更低的磁盘I/O。

    惟一扫描

    若是想只须要从索引中取一个值，可用惟一扫描(unique scan)。

    根据rowid获取

    当要查询索引行相关的列时，便会用到rowid，好比查询age=28(age上有索引，name无索引)的人的名字:

Select name from person where age = 28;

    以上的查询会按照：查询索引列age，过滤出age=28的全部行，而后按照查询出来的行号查name列，即先读索引再读表。但下面列子就不用读表了（name有索引）:

Select location.street from person, localtion where person.name = person.name;

    该方式在数据量不大时是比较有效的，但当数据量很大时，至关于全扫描了。

    其余获取方式

　　　以oracle为例。

    链接

    获取到数据后对数据进行链接运算，这里介绍三种链接方式:merge join, hash join,     nested loop join，以及引入inner relation和outer relation两个概念。关系数据库中定义了“关系”的定义，它能够是：一个表，一个索引以及前面运算的结果。

    链接两个关系时，数据库链接运算处理两个关系方式可能不一样，本文定义:

    链接运算符左边的关系称为outer relation；

    链接运算符右边的关系称为inner relation。

    好比a join b，a称为outer relation（常看见的是外表说法），b称为inner relation（常看见的是内表说法）。多数状况下 a join b 与b join a的成本是不同的。该部分假定outer relation有N个元素，inner relation有M个元素（实际状况下，这些信息数据库经过统计能够知道，如上部分）。

　嵌套循环链接（Nested loop join）:

　　  

　　　　　　　　　              　Fig. 11

　　通常分为两个步骤：

1. 读取outer relation 每一行
2. 检查inner relation中的每一行是否匹配链接

　　伪代码：  

nested_loop_join(array outer, array inner)
  for each row a in outer
    for each row b in inner
      if (match_join_condition(a,b))
        write_result_in_output(a,b)
      end if
    end for
  end for

　　显然时间复杂度为(N*M)。从磁盘I/O考虑，算法须要从磁盘读N+N*M行。可知，当M足够小时，只须要读N+M次，这样就能够把读取结果放到内存中，因此通常状况下都会将小的relation做为inner relation。

　　固然这虽然改善了磁盘I/O，时间复杂度并无变化。若是进一步优化磁盘I/O，还能够考虑将inner relation用索引来替换。　

　　考虑尽量将inner relation放到内存，作一个改进，基本思路：

1. 不逐行读取两个关系，而是分组读取，将组信息放到内存中；
2. 对比（内存中）的组间行，保留符合链接条件的行
3. 依次加载其余组直至对比两关系中全部组。

     伪代码

// improved version to reduce the disk I/O.
nested_loop_join_v2(file outer, file inner)
  for each bunch ba in outer
  // ba is now in memory
    for each bunch bb in inner
        // bb is now in memory
        for each row a in ba
          for each row b in bb
            if (match_join_condition(a,b))
              write_result_in_output(a,b)
            end if
          end for
       end for
    end for
   end for

 

　　该版本相比以前版本时间复杂度没有变化，但磁盘I/O明显变小了：number_of_bunches_for(outer)+ number_of_bunches_for(outer) * number_of_ bunches_for(inner)，并且可知增长分组的大小，即每次读取更多数据，还能继续减少读取次数。　

    哈希链接（hash join）

　　哈希链接更加复杂，但大多场合中比循环嵌套链接成本更低。

　　　　　　

　　　　　　　　　　　　　　　　　　Fig. 12

　　

　　基本思路：

1. 获取inner relation中的全部元素
2. （根据inner relation中的元素）构建一个常住内存hash table
3. 逐个获取outer relation全部元素
4. 计算每一个元素的哈希值(利用哈希函数计算哈希表)，与inner relation中的元素逐个比较，以肯定inner relation对应哪一个bucket
5. 肯定bucket与outer relation对应关系（buckt是否存在outer relation中元素）

　　分析其时间复杂度：inner relation分为x个buckets，outer relation与buckets对比的次数取决于buckets中的元素个数。哈希函数对各个关系中的元素是均匀分布的，也就是说buckets的大小是相同的。

　　时间复杂度：(M/X) * N + cost_to_create_hash_table(M) + cost_of_hash_function*N，当hash函数建立足够小的buckets时，好比buckets只有一个元素，那么时间复杂度能够为(M+N)。

　　内存占用更小磁盘I/O更小版本：

1. 对inner 和 outer relation都建立一个hash table
2. 把建立的hash tables放入磁盘
3. compare the 2 relations bucket by bucket (with one loaded in-memory and the other read row by row)

  Merge join　

　　Merge join是惟一产生排序结果的链接查询。

　　排序

　　在最开始介绍过归并排序，能够看到归并排序是一个很好的算法（固然若是不考虑内存状况下会有更好的算法，好比hash join）。但在如下条件时，通常会选择merge join。

1. 某个关系（表中）已经排好序
2. 某个关系链接条件建有索引
3. 链接条件产生的是中间结果，而该中间结果已经排序.

                             

　　　　　　　　　　　　　　　　　　　　　　Fig. 13

　　

　　Merge的过程和前面介绍的merge sort很类似，可是不会逐个读取两个关系元素，只会选择符合链接条件的元素。基本思路以下：

1. 对比两个relations的当前元素；
2. 若是两个元素相等，取出该元素，对比下面的元素；
3. 若是两个元素不相等，将较小元素进入下一次对比。
4. 重复以上，直到两个relations都处理到最后一个元素。

　　以上思路是在俩relations已经排好序且任一关系中不存在相同元素的简化模型下，具体的要复杂的多。

　　时间复杂度，若是两个relations已经排序好，复杂度为N+M；若是需先排序再链接，复杂度为(N*log(N)+M*log(M))。

　　伪代码

mergeJoin(relation a, relation b)
  relation output
  integer a_key:=0;
  integer  b_key:=0;
 
  while (a[a_key]!=null and b[b_key]!=null)
     if (a[a_key] < b[b_key])
      a_key++;
     else if (a[a_key] > b[b_key])
      b_key++;
     else //Join predicate satisfied
      write_result_in_output(a[a_key],b[b_key])
      //We need to be careful when we increase the pointers
      if (a[a_key+1] != b[b_key])
        b_key++;
      end if
      if (b[b_key+1] != a[a_key])
        a_key++;
      end if
      if (b[b_key+1] == a[a_key] && b[b_key] == a[a_key+1])
        b_key++;
        a_key++;
      end if
    end if
  end while

算法比较选择：

1. 内存的占用：若是没有足够的内存，基本要告别强大的 hash join （ 至少也告别全内存 hash join）。
2. 2个关系的数据量：好比要链接的两个表，一个数据量特别巨大，一个又很小很小，这时候 nested loop join 的效果要比 hash join 好，由于 hash join 给那个数据量巨大的表建立 hash 表就很费事。 若是两个表都有巨量的数据， nested loop join 链接方式的 CPU 负载会比较大；
3. 索引的方式： 若是链接的两个关系都有 B+树索引，那确定是 merge join 效果最好；
4. 结果是否须要排序： 若是但愿此次链接获得一个排序的结果（这样就可使用 merge join 方式实现下一个链接），或者查询自己（有 ORDER BY/GROUP BY/DISTINCT 运算符）要求的排序的结果；若是是这个状况，即便当前要链接的 2 个关系自己并无排好序， 依然建议选择稍微有点费事的 merge join（能够给出排序的结果）；
5. 链接的 2 个关系自己已经排序： 这个状况，必须用 merge join；
6. 链接类型： 若是是等值链接（好比： tableA.col1 = tableB.col2）？或者是内链接、外链接、笛卡尔积、自链接？有些链接方式可能不能处理这些不一样类型的链接；
7. 数据的分布： 若是链接条件的数据扭曲了（好比要链接表 PERSON 链接条件是列“姓”，可是意味的是不少人的姓是相同的），这个状况若是使用 hash join 必定会带来灾难，对吧？由于哈希函数计算后各个 buckets 上数据的分布确定存在巨大的问题 （有些 bucket 很小，只有一两个元素；而有些 buckets 太大，好几千的元素） 。

 

 下一篇将有一个简单的例子简要说明改过程。