myisam支援表鎖,不支援事務,支援全文索引,預設表型別.
innodb支援行鎖,支援事務,不支援全文索引(但可以用sphinx分詞索引);
行鎖級:share lock(別名:讀鎖,共享鎖,意向鎖),exclusivelock(別名:寫鎖,排他鎖 )
表鎖級: myisam:表共享讀鎖（table read lock）和表獨佔寫鎖（table write lock）
innodb:is(意向共享鎖),ix(意向排他鎖)
頁鎖:不常用(bdb引擎)
myisam:myisam只支援表鎖,所有的鎖機制是資料庫自動載入的,在select時加讀鎖,在update,insert,delete寫鎖,讀鎖只相容讀鎖,寫鎖排斥任何鎖!也就是說當表存在寫鎖時,其他的操作只能排隊等待了!
innodb:支援行鎖,簡單來說就是語句中使用到了索引,資料庫就對對應的行加鎖,如果沒有用到索引,則將全表加鎖.innodb在update,insert,delete給對應資料加排他鎖,select不加鎖.意向鎖是innodb自動加的，不需要使用者干預.
共享鎖:多個事務只能讀資料不能改資料,讀鎖和讀鎖之間不排斥
排他鎖:排他鎖指的是乙個事務在一行資料加上排他鎖後，其他事務不能再在其上加其他的鎖。
排他鎖: select.... for update (此時任何加鎖的資料不能被其他事務修改,也不能被加共享鎖的事務讀取,這些事務將會被阻塞,但是普通的select可以獲取到資料,因為innodb的select不加鎖)
共享鎖: select .....lock in share mode (此時其他事務的排他鎖會阻塞,共享鎖可以獲取資料,普通select也可以獲取資料)
表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖衝突的概率最高，併發度最低；
行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖衝突的概率最低，併發度也最高；
頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，併發度一般。
1、serializable （序列化）：最嚴格的級別，事務序列執行，資源消耗最大；
2、repeatable read（重複讀） ：保證了乙個事務不會修改已經由另乙個事務讀取但未提交（回滾）的資料。避免了「髒讀取」和「不可重複讀取」的情況，但不能避免「幻讀」，但是帶來了更多的效能損失。資料庫預設事務隔離等級
3、read committed （提交讀）：大多數主流資料庫的預設事務等級，保證了乙個事務不會讀到另乙個並行事務已修改但未提交的資料，避免了「髒讀取」，但不能避免「幻讀」和「不可重複讀取」。該級別適用於大多數系統。
4、read uncommitted（未提交讀） ：事務中的修改，即使沒有提交，其他事務也可以看得到，會導致「髒讀」、「幻讀」和「不可重複讀取」。
1、髒讀(drity read)：某個事務已更新乙份資料，另乙個事務在此時讀取了同乙份資料，由於某些原因，前乙個rollback了操作，則後乙個事務所讀取的資料就會是不正確的。[你獲取到了別人更改後的資料,但是人家只是說說 (事務回滾)]
2、不可重複讀(non-repeatable read):在乙個事務的兩次查詢之中資料不一致，這可能是兩次查詢過程中間插入了乙個事務更新的原有的資料。[當前資料被其他事務修改,資料獲取後,其他事務回滾了]
3、幻讀(phantom read):在乙個事務的兩次查詢中資料筆數不一致，例如有乙個事務查詢了幾列(row)資料，而另乙個事務卻在此時插入了新的幾列資料，先前的事務在接下來的查詢中，就會發現有幾列資料是它先前所沒有的[其他事務增加了符合條件的資料別你獲取到了,但是其他事務回滾並沒有提交] 資料庫預設隔離級別為repeatable read,此級別會導致幻讀!
悲觀鎖和樂觀鎖只是對資料驗證的兩種不同方式!只是一種概念
悲觀鎖:對資料的修改持以保守的態度,是利用資料庫的鎖機制,對修改的資料加排他鎖!
樂觀鎖：相對悲觀鎖而言，樂觀鎖假設認為資料一般情況下不會造成衝突，所以在資料進行提交更新的時候，才會正式對資料的衝突與否進行檢測, 較為盛行的方法有兩種
1）.使用資料版本（version）記錄機制實現，這是樂觀鎖最常用的一種實現方式。何謂資料版本？即為資料增加乙個版本標識，一般是通過為資料庫表增加乙個數字型別的 「version」 欄位來實現。當讀取資料時，將version欄位的值一同讀出，資料每更新一次，對此version值加一。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的version值進行比對，如果資料庫表當前版本號與第一次取出來的version值相等，則予以更新，否則認為是過期資料。
2）.樂觀鎖定的第二種實現方式和第一種差不多，同樣是在需要樂觀鎖控制的table中增加乙個字段，名稱無所謂，字段型別使用時間戳（timestamp）, 和上面的version類似，也是在更新提交的時候檢查當前資料庫中資料的時間戳和自己更新前取到的時間戳進行對比，如果一致則ok，否則就是版本衝突。
兩種鎖各有優缺點，不可認為一種好於另一種，像樂觀鎖適用於寫比較少的情況下，即衝突真的很少發生的時候，這樣可以省去了鎖的開銷，加大了系統的整個吞吐量。但如果經常產生衝突，上層應用會不斷的進行retry，這樣反倒是降低了效能，所以這種情況下用悲觀鎖就比較合適。另外，高併發情況下個人認為樂觀鎖要好於悲觀鎖，因為悲觀鎖的機制使得各個執行緒等待時間過長，極其影響效率，樂觀鎖可以在一定程度上提高併發度!
個人認為 :如果要保持資料的一致性,連貫性,準確性,就要用悲觀鎖.適用場景:下單,秒殺
參照:
mysql 鎖 事務隔離級別
最近在看mysql相關的書籍.實驗了一些內容.分享一下,主要是關於事務隔離級別 read committed和repeatable read 和鎖相關的.很多網上文章上都能搜尋到 read committed可以防止髒資料.但是不能防止 不可重複讀.而repeatable read可以防止 不可重複...
mysql鎖問題 事務隔離級別
相對其他資料庫而言，mysql的鎖機制比較簡單，其最顯著的特點是不同的儲存引擎支援不同的鎖機制。innodb最大的特點就是一是支援事務 transaction 二是採用了行級鎖。所以我們先來引申一下事務和事務隔離級別的知識。1.1 事務以及acid屬性 事務是由一組sql語句組成的邏輯處理單元，事務...
mysql事物鎖鎖表 mysql 事務 行鎖 表鎖
一 準備 select from information schema.innodb trx 查詢事務 select from information schema.innodb locks 查詢鎖 select from information schema.innodb lock waits 暫...