深入淺出MySQL事務處理和鎖機制

?

2015-01-13?架構師之旅 1. 事務處理和并發性 1.1. 基礎知識和相關概念 1 ）全部的表類型都可以使用鎖，但是只有 InnoDB 和 BDB 才有內置的事務功能。 2 ）使用 begin 開始事務，使用 commit 結束事務，中間可以使用 rollback 回滾事務。 3 ）在默認情況下， InnoDB 表支持一致讀。 SQL 標準中定義了 4 個隔離級別： read uncommited ， read commited ， repeatable read ， serializable 。 read uncommited 即臟讀，一個事務修改了一行，另一個事務也可以讀到該行。 如果第一個事務執行了回滾，那么第二個事務讀取的就是從來沒有正式出現過的值。 ? read commited 即一致讀，試圖通過只讀取提交的值的方式來解決臟讀的問題，但是這又引起了不可重復讀取的問題。 一個事務執行一個查詢，讀取了大量的數據行。在它結束讀取之前，另一個事務可能完成了對數據行的更改。當第一個事務試圖再次執行同一個查詢，服務器就會返回不同的結果。 repeatable read 即可重復讀，在一個事務對數據行執行讀取或寫入操作時鎖定了這些數據行。 但是這種方式又引發了幻想讀的問題。 因為只能鎖定讀取或寫入的行，不能阻止另一個事務插入數據，后期執行同樣的查詢會產生更多的結果。 serializable 模式中，事務被強制為依次執行。這是 SQL 標準建議的默認行為。 4 ）如果多個事務更新了同一行，就可以通過回滾其中一個事務來解除死鎖。 5 ） MySQL 允許利用 set transaction 來設置隔離級別。 6 ）事務只用于 insert 和 update 語句來更新數據表，不能用于對表結構的更改。執行一條更改表結構或 begin 則會立即提交當前的事務。 7 ）所有表類型都支持表級鎖，但是 MyISAM 只支持表級鎖。 8 ）有兩種類型的表級鎖：讀鎖和寫鎖。 讀鎖是共享鎖，支持并發讀，寫操作被鎖。 寫鎖是獨占鎖，上鎖期間其他線程不能讀表或寫表。 8 ）如果要支持并發讀寫，建議采用 InnoDB 表，因為它是采用行級鎖，可以獲得更多的更新性能。 9 ）很多時候，可以通過經驗來評估什么樣的鎖對應用程序更合適，不過通常很難說一個鎖比別的更好，這全都要依據應用程序來決定，不同的地方可能需要不同的鎖。當前 MySQL 已經支持 ISAM, MyISAM, MEMORY (HEAP) 類型表的表級鎖了， BDB 表支持頁級鎖， InnoDB 表支持行級鎖。 10 ） MySQL 的表級鎖都是寫鎖優先，而且是采用排隊機制，這樣不會出現死鎖的情況。對于 InnoDB 和 BDB 存儲引擎來說，是可能產生死鎖的。這是因為 InnoDB 會自動捕獲行鎖， BDB 會在執行 SQL 語句時捕獲頁鎖的，而不是在事務的開始就這么做。 1.2. 不同鎖的優缺點及選擇 行級鎖的優點及選擇 ： 1 ）在很多線程請求不同記錄時減少沖突鎖。 2 ）事務回滾時減少改變數據。 3 ）使長時間對單獨的一行記錄加鎖成為可能。 行級鎖的缺點 ： 1 ）比頁級鎖和表級鎖消耗更多的內存。 2 ）當在大量表中使用時，比頁級鎖和表級鎖更慢，因為他需要請求更多的所資源。 3 ）當需要頻繁對大部分數據做 GROUP BY 操作或者需要頻繁掃描整個表時，就明顯的比其它鎖更糟糕。 4 ）使用更高層的鎖的話，就能更方便的支持各種不同的類型應用程序，因為這種鎖的開銷比行級鎖小多了。 5 ）可以用應用程序級鎖來代替行級鎖，例如 MySQL 中的 GET_LOCK() 和 RELEASE_LOCK() 。但它們是勸告鎖（原文： These are advisory locks ），因此只能用于安全可信的應用程序中。 6 ）對于 InnoDB 和 BDB 表， MySQL 只有在指定用 LOCK TABLES 鎖表時才使用表級鎖。在這兩種表中，建議最好不要使用 LOCK TABLES ，因為 InnoDB 自動采用行級鎖， BDB 用頁級鎖來保證事務的隔離。 表鎖的優點及選擇： 1 ）很多操作都是讀表。 2 ）在嚴格條件的索引上讀取和更新，當更新或者刪除可以用單獨的索引來讀取得到時： UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;DELETE FROM tbl_name WHERE unique_key_col=key_value; 3 ） SELECT 和 INSERT 語句并發的執行，但是只有很少的 UPDATE 和 DELETE 語句。 4 ）很多的掃描表和對全表的 GROUP BY 操作，但是沒有任何寫表。 表鎖的缺點： 1 ）一個客戶端提交了一個需要長時間運行的 SELECT 操作。 2 ）其他客戶端對同一個表提交了 UPDATE 操作，這個客戶端就要等到 SELECT 完成了才能開始執行。 3 ）其他客戶端也對同一個表提交了 SELECT 請求。由于 UPDATE 的優先級高于 SELECT ，所以 SELECT 就會先等到 UPDATE 完成了之后才開始執行，它也在等待第一個 SELECT 操作。 1.3. 如何避免鎖的資源競爭 1 ）讓 SELECT 速度盡量快，這可能需要創建一些摘要表。 2 ）啟動 mysqld 時使用參數 --low-priority-updates 。這就會讓更新操作的優先級低于 SELECT 。 這種情況下，在上面的假設中，第二個 SELECT 就會在 INSERT 之前執行了，而且也無需等待第一個 SELECT 了。 3 ）可以執行 SET LOW_PRIORITY_UPDATES=1 命令，指定所有的更新操作都放到一個指定的鏈接中去完成。 4 ）用 LOW_PRIORITY 屬性來降低 INSERT ， UPDATE ， DELETE 的優先級。 5 ）用 HIGH_PRIORITY 來提高 SELECT 語句的優先級。 6 ）從 MySQL 3.23.7 開始，可以在啟動 mysqld 時指定系統變量 max_write_lock_count 為一個比較低的值，它能強制臨時地提高表的插入數達到一個特定值后的所有 SELECT 操作的優先級。它允許在 WRITE 鎖達到一定數量后有 READ 鎖。 7 ）當 INSERT 和 SELECT 一起使用出現問題時，可以轉而采用 MyISAM 表，它支持并發的 SELECT 和 INSERT 操作。 8 ）當在同一個表上同時有插入和刪除操作時， INSERT DELAYED 可能會很有用。 9 ）當 SELECT 和 DELETE 一起使用出現問題時， DELETE 的 LIMIT 參數可能會很有用。 10 ）執行 SELECT 時使用 SQL_BUFFER_RESULT 有助于減短鎖表的持續時間。 11 ）可以修改源代碼 `mysys/thr_lock.c' ，只用一個所隊列。這種情況下，寫鎖和讀鎖的優先級就一樣了，這對一些應用可能有幫助。 posted on 2018-08-11 21:42 micwin 閱讀(...) 評論(...) ?編輯 收藏

轉載于:https://www.cnblogs.com/chinanetwind/articles/9461213.html

總結

以上是生活随笔為你收集整理的深入浅出MySQL事务处理和锁机制的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。