樂觀鎖和悲觀鎖

併發控制機制

    最經常使用的處理多用戶併發訪問的方法是加鎖。當一個用戶鎖住數據庫中的某個對象時，其餘用戶就不能再訪問該對象。加鎖對併發訪問的影響體如今鎖的粒度上。好比，放在一個表上的鎖限制對整個表的併發訪問；放在數據頁上的鎖限制了對整個數據頁的訪問；放在行上的鎖只限制對該行的併發訪問。可見行鎖粒度最小，併發訪問最好，頁鎖粒度最大，表鎖介於2者之間。

悲觀鎖：假定會發生併發衝突，屏蔽一切可能違反數據完整性的操做。 悲觀鎖假定其餘用戶企圖訪問或者改變你正在訪問、更改的對象的機率是很高的，所以在悲觀鎖的環境中，在你開始改變此對象以前就將該對象鎖住，而且直到你提交了所做的更改以後才釋放鎖。悲觀的缺陷是不管是頁鎖仍是行鎖，加鎖的時間可能會很長，這樣可能會長時間的限制其餘用戶的訪問，也就是說悲觀鎖的併發訪問性很差。

樂觀鎖：假設不會發生併發衝突，只在提交操做時檢查是否違反數據完整性。樂觀鎖不能解決髒讀的問題。    樂觀鎖則認爲其餘用戶企圖改變你正在更改的對象的機率是很小的，所以樂觀鎖直到你準備提交所做的更改時纔將對象鎖住，當你讀取以及改變該對象時並不加鎖。可見樂觀鎖加鎖的時間要比悲觀鎖短，樂觀鎖能夠用較大的鎖粒度得到較好的併發訪問性能。可是若是第二個用戶剛好在第一個用戶提交更改以前讀取了該對象，那麼當他完成了本身的更改進行提交時，數據庫就會發現該對象已經變化了，這樣，第二個用戶不得不從新讀取該對象並做出更改。這說明在樂觀鎖環境中，會增長併發用戶讀取對象的次數。

     從數據庫廠商的角度看，使用樂觀的頁鎖是比較好的，尤爲在影響不少行的批量操做中能夠放比較少的鎖，從而下降對資源的需求提升數據庫的性能。再考慮彙集索引。在數據庫中記錄是按照彙集索引的物理順序存放的。若是使用頁鎖，當兩個用戶同時訪問更改位於同一數據頁上的相鄰兩行時，其中一個用戶必須等待另外一個用戶釋放鎖，這會明顯地下降系統的性能。interbase和大多數關係數據庫同樣，採用的是樂觀鎖，並且讀鎖是共享的，寫鎖是排他的。能夠在一個讀鎖上再放置讀鎖，但不能再放置寫鎖；你不能在寫鎖上再放置任何鎖。鎖是目前解決多用戶併發訪問的有效手段（Dirty Read 一個事務讀到了另一個事務未提交的新數據。）

----以上手冊中的理論知識;
===========================================================================================
       隔離級別               髒讀（Dirty Read）          不可重複讀（NonRepeatable Read）     幻讀（Phantom Read） 
===========================================================================================

未提交讀（Read uncommitted）        可能                            可能                       可能

已提交讀（Read committed）          不可能                          可能                        可能

可重複讀（Repeatable read）          不可能                          不可能                     可能

可串行化（Serializable ）                不可能                          不可能                     不可能

===========================================================================================

·未提交讀(Read Uncommitted)：容許髒讀，也就是可能讀取到其餘會話中未提交事務修改的數據

·提交讀(Read Committed)：只能讀取到已經提交的數據。Oracle等多數數據庫默認都是該級別 (不重複讀)

·可重複讀(Repeated Read)：可重複讀。在同一個事務內的查詢都是事務開始時刻一致的，InnoDB默認級別。在SQL標準中，該隔離級別消除了不可重複讀，可是還存在幻象讀

·串行讀(Serializable)：徹底串行化的讀，每次讀都須要得到表級共享鎖，讀寫相互都會阻塞

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

3.Phantom Read 

一個事務執行了兩次查詢操做（例如統計具備某特性的數據行數），可是兩次查詢操做中間，有其餘事務插入了新數據或者刪除了數據，形成兩次結果不一致。

轉載：http://www.cnblogs.com/zhoujinyi/p/3437475.html

不可重複讀:是指在一個事務內，屢次讀同一數據。在這個事務尚未結束時，另一個事務也訪問該同一數據。那麼，在第一個事務中的兩次讀數據之間，因爲第二個事務的修改，那麼第一個事務兩次讀到的的數據多是不同的。這樣就發生了在一個事務內兩次讀到的數據是不同的，所以稱爲是不可重複讀。