當前位置:網站首頁>MySQL事務隔離

MySQL事務隔離

2022-06-23 23:08:30知其黑、受其白

事務的介紹

事務就是一組原子性的 sql 查詢,或者說是一個獨立的工作單元。
簡而言之,事務內的語句要麼全部執行成功,要麼全部執行失敗。

在 MySQL 中,事務支持是在引擎層實現的,但並不是所有的 MySQL 引擎都支持事務,比如 MyISAM 引擎就不支持事務,這也是 MyISAM 被 InnoDB 取代的重要原因之一。

提到事務,我們肯定會想到 ACID:

原子性(Atomicity)
一致性(Consistency)
隔離性(Isolation)
持久性(Durability)

隔離級別

當數據庫中有多個事務同時執行時,就可能會出現髒讀、不可重複讀、幻讀等問題,因為就有了事務隔離級別的概念。

SQL標准正定義了四種隔離級別:

1 READ UNCOMMITTED (未提交讀)

事務中的修改,即使還沒有提交,對其他事務都是可見的。事務可以讀取未提交的數據,也被稱為髒讀(Dirty Read)。

2 READ COMMITTED(提交讀)

一個事務提交後,所做的變更才能被其他事務看到。這個級別也叫不可重複讀,因為事務中執行2次相同的查詢,可能得到的結果是不一樣的。

3 REPEATABLE READ(可重複讀)

一個事務執行的過程中,總是和這個事務在啟動時看到的數據是一致的。當然在這個級別下,未提交的數據變更對其他事務也是不可見的。

SERIALIZABLE(可串行化)

對同一行記錄,寫和讀都會加鎖,當出現讀寫鎖沖突時,後訪問的事務必須等前一個事務執行完成才能繼續執行,就會導致大量的超時和鎖爭用的問題。


在實現上,數據庫裏面會創建一個視圖,訪問的時候以視圖的邏輯為准。

在可重複讀這個隔離級別下,
這個視圖是事務開啟的時候創建的,整個事務期間都用這個視圖。

在讀提交的隔離級別下,這個視圖是在 sql 語句開始執行的時候創建的。

在讀未提交的隔離級別下,直接返回記錄上的最新值,沒有視圖概念。

在串行化的隔離級別下,直接用加鎖的方式避免並行訪問。

配置的方式是將啟動參數 transaction-isolation 設置成想要的隔離級別。

查看當前設置:

mysql> show variables like 'transaction_isolation';
+-----------------------+-----------------+
| Variable_name         | Value           |
+-----------------------+-----------------+
| transaction_isolation | REPEATABLE-READ |
+-----------------------+-----------------+
1 row in set (0.00 sec)

總之,存在即合理,不同的隔離級別適用於不同的場景,具體我們應該根據業務場景來决定。

事務隔離的實現

在Mysql中,實際上每條記錄的更新同時也會記錄一條回滾操作,記錄上的最新值通過回滾操作,都可以得到前一個狀態的值。

系統會自動判斷,當沒有事務再需要回滾日志時,會删除回滾日志。

為什麼不建議使用長事務:

長事務意味著系統裏面會存在很老的事務視圖,由於這些事務隨時可以訪問數據庫裏面的任何數據,所以這個事務提交之前,數據庫裏可能用到的回滾記錄必須保留著,這就會占用大量的存儲空間。同時長事務還占用鎖資源,也可能拖垮整個庫。

事務啟動的方式

1 顯式啟動事務語句,begin 或者 start transaction ,提交就是 commit ,回滾用 rollback

2 set autocommit = 0,這個命令會將線程的自動提交關掉,意味著如果執行一個select 語句,這個事務就啟動了,並且不會自動提交,直到你主動執行 commit 或者 rollback,或者斷開連接。

個人建議還是通過第一種方式顯式啟動事務,避免長事務的發生。

set autocommit = 1 的情况下,用 begin 顯式啟動的事務,如果執行 commit 則提交事務。如果執行 commit work and chain,則是提交事務並自動啟動下一個事務,這樣也省去了再次執行 begin 語句的開銷。

查詢長事務:

下面語句是查詢持續時間超過60s的事務:

mysql> select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60;
Empty set (0.00 sec)

總結下來,我們在開發過程中,盡量少用長事務,如果無法避免,保證邏輯日志空間足够大,並且支持動態日志空間增長。監控 Innodb_trx錶,發現長事務報警。

版權聲明
本文為[知其黑、受其白]所創,轉載請帶上原文鏈接,感謝
https://cht.chowdera.com/2022/174/202206231906098908.html

隨機推薦