[TOC] ### 讀寫鎖 在處理并發讀或寫時，可以通過實現一個由兩種類型讀鎖著稱讀鎖系統來解決問題。這兩種鎖通常備成為共享鎖和排他鎖，也叫讀鎖和寫鎖。 **讀鎖** ``` 讀鎖是共享的，是相互不阻塞的。多個客戶在同一時刻可以同時讀取同一個資源，而互相不干擾。 ``` **寫鎖** ``` 寫鎖則是排他的，一個寫鎖會阻塞其他的寫鎖和讀鎖 ``` ### 鎖粒度 鎖策略，在鎖的開銷和數據的安全性之間尋求平衡。 #### 表鎖 表鎖是MySQL中最基本的鎖策略，并且是開銷最小的策略。 ``` 表鎖會鎖定整張表。一個用戶在對表進行寫操作前，需要先獲得寫鎖，這回阻塞其他用戶對該表的所有讀寫操作。 只有沒有寫鎖的時候其他讀取的用戶才能獲得讀鎖，讀鎖之間是不相互阻塞的。 ``` #### 行級鎖 行級鎖可以最大程度的支持并發處理(同時也帶來來最大的鎖開銷)-行級鎖只在存儲引擎層實現，而不是MySQL服務器層。 ### 事務 事務是一組原子性的SQL查詢，或者說一個獨立的工作單元。 ``` 如果數據庫引擎能夠成功的對數據庫應用該組查詢的全部語句，那么就執行該組查詢，如果有任何一條語句因崩潰無法執行，則所有的語句都不會執行。 事務內的語句，要么全部執行，要么全部失敗。 ``` #### 良好事務處理系統的特征： ``` 原子性 一致性 隔離性 持久性 ``` #### **隔離級別**： **READ UNCOMMITTED**（未提交讀寫） ``` 事務中的修改，即使沒有提交，對其他事務也都是可見的。事務可以讀取未提交的數據，這也被稱為臟讀。 ``` **READ COMMITTED**（提交讀） ``` READ COMMITTED是大多數數據庫系統默認隔離級別，但是MySQL不是。 一個事務開始時，只能“看見“已經提交的事務所做的修改。也叫不可重復讀。 ``` **REPEATABLE READ**（可重復讀） ``` 解決來臟讀的問題。該級別保證了在同一個事務中多次讀取同樣的記錄的結果是一致的。 無法解決另外一個幻讀的問題。 幻讀：當某個事務在讀取某個范圍內的記錄時，另外一個事務又在該范圍內插入了新的記錄，當之前的事務再次讀取該范圍的記錄時，會產生幻行。 InnoDB和XtraDB存儲引擎通過多版本并發控制解決了幻讀的問題。 ``` **SERIALIZABLE**（可串行化） ``` SERIALIZABLE是最高的隔離級別。通過強制事務串行執行，避免幻讀的問題。 SERIALIZABLE會在讀取的每一行數據上都加鎖，所以可能導致超時和鎖爭用的問題。實際上很少用，只會在非常需要確保詩句的一致性而且可以接收沒有并發的情況下。 ```  #### 死鎖 死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方占用的資源，從而導致惡性循環的現象。 **InnoDB目前處理死鎖的方法** ``` 將持有最少行級排他鎖的事務進行回滾 ``` #### 事務日志 事務日志可以幫助提高效率。村村引擎在修改表的數據時只需要修改其內存拷貝，再把該修改行為記錄到持久在硬盤上的事務日志中，而不用每次都將修改的數據本身持久到硬盤上。 事務日志此啊用的是追加的方式。 #### MySQL中的事務 **自動提交** MySQL默認采用自動提交 ``` set autocommit = 1; ``` 設置隔離級別: ``` set transaction isolation level ``` #### 在事務中混合使用存儲引擎 MySQL服務器層不管里事務，事務是由下層的存儲引擎實現的，所以在同一個事務中，使用多種存儲引擎是不可靠的。 如果在事務中混合使用了事務型和非事務型(InnoDB和MyISAM)，在正常提交下不會有問題，但是如果該事務需要回滾，非事務型的表上變更就無法撤銷，這會導致數據庫處于一種不一致的狀態，這中情況很難修復。 #### 隱式和顯式鎖定 InnoDB采用的是兩階段鎖定協議。在事務執行過程中，隨時可以執行鎖定，鎖只有在執行COMMIT或者ROLLBACK的時候才會釋放。并且所有的鎖都是在同一時刻釋放。前面的鎖是隱式鎖定，InnoDB會根據隔離級別在需要的時候自動加鎖。 如果從MyISAM轉換到InnoDB，則不要顯式地使用LOCK TABLES語句，這會嚴重但影響性能。InnoDB但行級鎖工作的更好。