數據庫作為計算機學科中一個比較重要的分支，也是一個對于程序員來說非常好的學習方向。平時我們用的最多的，同時也是接觸最多的一定是增刪改查語句，select, update,delete等，當然，我不會拿這些再說一遍，這些都是老的掉渣的東西了。所以我們可以學習高級

數據庫作為計算機學科中一個比較重要的分支，也是一個對于程序員來說非常好的學習方向。平時我們用的最多的，同時也是接觸最多的一定是增刪改查語句，select,

update,delete等，當然，我不會拿這些再說一遍，這些都是老的掉渣的東西了。所以我們可以學習高級數據庫中所以涉及的技術。換句話，其實就是拋開業務層的邏輯，從更加深層次的角度理解數據庫。今天我主要提交3個技術點，

1.數據索引技術，典型的B+樹索引系列

2.數據庫故障恢復技術，我這里只提的是基于日志的恢復技術

3.數據庫系統結構，講講時下流行的分布式數據庫系統

數據庫索引技術關系著數據的查詢速度，當數據量比較小的時候，響應是沒有問題，當數據庫中擁有百萬，千萬級數據量的數據時，建立索引是必須的。傳統的數據查詢操作時在海量數據中一條條的查詢，在磁盤塊中逐個尋找效率當然不高，如果是連續存儲的還算運氣好，如果是物理上不連續的，那結果可想而知。所以在這里我們引入了一個名叫“index”索引概念的東西，他不保存真實的數據，索引其實是一個指向真實數據記錄的地址指針，要查詢的數據的時候，先找到此索引值，然后根據此索引值，找到真實記錄地址，因為不保存真實數據，索引查詢的速度比較快。首先我們說說順序索引，順序索引的定義是當數據文件的存儲順序是按某個索引鍵值的順序排列時，稱該文件為順序文件，為順序文件建立索引的時候，一般此索引的建立以某個索引鍵一致，比如說某ID建立的索引為順序索引，順序文件的索引可以采用二分查找方法能夠很快定位到相應的索引記錄。B+樹索引是以平衡樹的結構構建的索引，B+樹憑借其特殊的結構設計，一直保持著一種比較高的查詢效率，在我之前的文章中也都提到過了。最后說的是散列索引，散列索引是利用哈希函數將搜索鍵值，分別映射到M個記錄搜索鍵值存儲地址的桶中，這樣可以利用哈希算法直接檢索，我們都知道哈希算法，的速度是相當快的哦，但是同時此時的一個好的哈希算法就顯得至關重要了，最好能將索引記錄均勻地分布到各個桶中。

基于日志的恢復技術也是數據庫容災處理的一部分，這里的日志主要有3個，undo，redo，undo/redo三種。undo，從這個英文中我們也可大概知道他的意思是不要做，就是撤銷操作的意思了,一般我們在操作未完全完成的情況下才會執行撤銷動作，這樣可以避免臟數據的誕生。undo的日志就是為了防止出現這個情況的。undo的日志記錄結構為：

其中:T是更新數據的事務，X是T更新的數據元素，V是更新前的舊值，數據出錯了就是拿這個值更新回去的，一個完整的undo日志記錄如下:

//開啟事務

//對數據A 進行了數據更改，把他的舊值記錄下來

//對數據B進行了數據操作，把B的舊值也記錄下來

//事務執行成功，也記錄

如果在commit 操作之前系統故障了，也就是沒有寫入記錄中，也不知道數據操作到底對不對，日志統一從后往前逆序讀取，首先遇到 ,將B更新到舊值10，然后又遇到 ，將A還原回到10，直到遇到 ,說明事物恢復成功，又回到了事物的出發點日志恢復結束。undo日志的事務執行順序為：

(1).寫更新數據量元素的日志

(2).再寫更新的數據元素

(3).最后寫COMMIT，表明事務已經成功提交

但是在這里其實會暴露一個潛在的問題，此要求事務必須將所做的修改寫到磁盤后才能提交事務，這無疑增加了I/O開銷，實際上，我們可以將數據的修改操作暫緩寫到磁盤上，等到緩沖區滿時再寫入磁盤，就可以節省很多I/O操作了，于是就有了redo日志的出現，redo日志的格式與undo日志略有區別：

(1).寫更新數據量元素的日志

(2).再寫COMMIT，表明事務已經成功提交

(3).最后寫更新的數據元素