深入淺出MySQL事務(wù)處理和鎖機制

?

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

轉(zhuǎn)載于:https://www.cnblogs.com/chinanetwind/articles/9461213.html

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。