(十二)數據庫查詢處理之Query Execution(1)

(十二)數據庫查詢處理之Query Execution(1)

1. 寫在前面

1. 這一大部分就是爲了Lab3作準備的
2. 每個query plan都要實現一個next函數和一個init函數

對於next函數每次調用時，返回一個元組或空標記（若是沒有更多元組

2. 迭代模型(ITERATOR MODEL)

對於上面這個圖的理解就是獲取全部的r.id而後構建hash表

而後在right的關係中獲取出全部知足要求的S.ID

這裏的evalPred(t)就等價於 S.value > 100

幾乎全部的DBMS都是用上面的方法。可是容許咱們流水線化的實現

不過一些操做必須是順序化的如Joins、Order By

3. MATERIALIZATION 模型

一次處理全部輸入，而後一次得到它的全部輸出。

能夠發現這種實現沒有了next函數(能夠把next理解成一種迭代器)

而是在一個list中放了全部知足要求的輸入。而後最後也是得到全部輸出

對於OLTP(主要是對數據的增刪改)工做負載更好，由於一次訪問少許元組。→下降執行/協調開銷。→更少的函數調用。

Not good for OLAP(主要是對於大型數據的分析) queries with large intermediate results.

4. VECTORIZATION 模型

和上面模型的區別是這種模型用batch代替了所有

這種方法適合OLAP由於它大大減小了每一個運算符的執行次數

5. 對於順序掃描的優化

DBMS能夠訪問存儲於table中的數據的最簡單方法莫過於順序掃描法

for page in table.pages:
	for t in page.tuples:
		if (check(t)):
		  // DO something

很顯然這種方法很差。下面來看一些對於這個方法的簡單優化

1. Zone MAPS

先維護一些關於這個page 的信息

對於這個page那們咱們若是要執行

SELECT * FROM TABLE WHERE val > 500

咱們就不用訪問這個page了由於咱們經過Zone Map 知道了這個page裏最大的val爲400.

2. LATE MATERIALIZATION

DBMS能夠延遲拼接元組。到最上層的操做再進行元祖拼接

對於上面，這個操做而言咱們進行一些分析

1. 獲取a表中知足要求的行號好比(0 ,1,3)並往上傳遞
2. 獲取b中在(0,1,3)行知足要求的行號好比(0,3)而後繼續往上傳遞
3. 在最上層元素咱們就能夠直接在c中的(0,3)行進行AVG操做

3. HEAP CLUSTERING

就是前面說過的聚簇索引。

6. index scan

1. 多index scan

這個比較簡單對於每個索引根據條件獲取一個集合。而後把集合結合起來最後根據另外一個查詢條件得到結果

2. INDEX SCAN PAGE SORTING

檢索元組在非聚簇索引中是十分低效的

DBMS能夠根據page id對於元組進行排序。這樣就能夠把咱們隨機訪問變成順序訪問

7. EXPRESSION EVALUATION

當執行語句發生的時候。咱們會有一個Execution Context的東西來保存咱們的上下文

上下文中包含

當前元組 
執行的參數
Table的Scheme

8.總結

1. 相同的query plan 會有不一樣的執行方法
2. 要儘量多的利用index scan
3. 表達式樹雖然很直觀可是很是慢