索引型別：
• b+樹索引
• 全文索引
• 雜湊索引
b+樹索引時最為常用和最為有效的索引，
b+樹索引並不能查詢乙個給定鍵值的具體行
查詢流程：
查詢資料所在的頁->將頁讀入記憶體->在記憶體中查詢資料
b+樹的層數一般是2-4層，查詢鍵值只要2-4次io操作，查詢時間只需0.02～0.04秒
聚集索引（clustered index） 就是按照每張表的主鍵構造一棵b+樹， 同時葉子節點中存放的即為整張表的行記錄資料， 也將聚集索引的葉子節點稱為資料頁
聚集索引的儲存並不是物理上連續的， 而是邏輯上連續的
衝突機制：採用鍊錶方式
雜湊函式：除法雜湊
h(k)=k mod m
m的取值為略大於2倍的緩衝池頁數量的質數
資料庫系統區別於檔案系統的乙個關鍵特性
用途：對共享資源的併發訪問，提供資料的完整性和一致性
在行級別上對錶資料上鎖
latch 閂鎖，輕量級的鎖 鎖定時間非常短 操作物件是執行緒
lock 操作物件是事務
• 共享鎖[s lock]：允許事務讀一行資料
• 排它鎖 [x lock]：允許事務刪除或更新一行資料
兩種意向鎖：
1） 意向共享鎖（is lock） ， 事務想要獲得一張表中某幾行的共享鎖
2） 意向排他鎖（ix lock） ， 事務想要獲得一張表中某幾行的排他鎖
鎖會帶來三種問題：髒讀，不可重複讀，丟失更新
重要概念區分
髒頁：在緩衝池中已經修改的頁，但是還未重新整理到磁碟中。不影響資料的一致性，提高效能
髒資料：事務對緩衝池中行記錄的修改，還沒有被提交commit。
讀到髒資料，即乙個事務可以讀到另外乙個事務中未提交的資料。違反事務的隔離性
不可重複讀：在同乙個事務中讀取同一條記錄多次次，得到的結果不一致，由於在2次讀取之間另外乙個事務對此行資料進行了修改。
違反一致性
不可重複讀的問題定義為phantom problem
innodb儲存引擎的預設事務隔離級別是read repeatable， 採用next-key lock演算法， 避免了不可重複讀的現象
乙個事務的更新操作會被另乙個事務的更新操作所覆蓋， 從而導致資料的不一致。
解決辦法：序列化操作，加x鎖
乙個事務中的鎖等待另乙個事務的鎖釋放它所佔的資源
死鎖是指兩個或兩個以上的事務在執行過程中， 因爭奪鎖資源而造成的一種互相等待的現象
解決辦法：等待轉換為回滾，並且事務重新開始
最簡單的一種方法：超時—-超過時間閾值回滾，另乙個事務執行。
普遍的方式：等待圖wait-for graph 【innodb儲存採用 】
要求儲存兩種資訊：鎖的資訊鍊錶，事務等待鍊錶。
死鎖後回滾undo量最小的事務。
死鎖只存在於併發的情況。
阻塞 blocking 第6章 鎖
expert oracle database architecture學習筆記 阻塞 blocking 第6章.鎖 如果乙個會話持有某個資源的鎖，而另乙個會話在請求這個資源，就會出現阻塞 blocking 幾乎在所有情況下，阻塞都是可以避免的。實際上，如果你真的發現會話在乙個互動式應用中被阻塞，就說...
演算法導論 第6章
這一章，前言講了為什麼要排序？接著介紹本章主題，堆排序。那麼什麼又是堆呢？一種資料結構，當然有很多性質，這個我在前面資料結構說過了，然後有兩種。1.大根堆 它是用來堆排序的。2.小根堆 它是用來做優先順序佇列的。清楚了這兩種用途，那麼我們來看 關於堆排序 public class heap sort...
演算法導論 第5章
這一章，說來說去，兩件事情，1.概率分析。2.隨機演算法。先把這個僱傭問題拿出來。問題 有一批參與面試的人，你要乙個個面試 面試每個人都要花費c1 如果當前面試者比自己的助理能力強，則辭掉當前助理的，並把當前面試者提拔為助理 僱傭乙個人要花費c2 一直面試完所有人。這裡考慮的是面試所花的money，...