回覆列表
-
1 # 程式猿W
-
2 # 愛可生雲資料庫
1.普通事務以 begin / start transaction 開始,commit / rollback 結束的事務。或者是帶有儲存點 savepoint 的事務。2. 鏈式事務一個事務在提交的時候自動將上下文傳給下一個事務,也就是說一個事務的提交和下一個事務的開始是原子性的,下一個事務可以看到上一個事務的處理結果。MySQL 的鏈式事務靠引數 completion_type 控制,並且回滾和提交的語句後面加上 work 關鍵詞。3. 巢狀事務有多個 begin / commit / rollback 這樣的事務塊的事務,並且有父子關係。子事務的提交完成後不會真的提交,而是等到父事務提交才真正的提交。4. 自治事務內部事務的提交不隨外部事務的影響,一般用作記錄內部事務的異常情況。MySQL 不支援自治事務,但是某些場景可以用 MySQL 的外掛式引擎來變相實現。
-
3 # 技術分享realize
Mysql事務一般處理複雜資料,進行操作的過程中,如果出錯,那麼回滾,如果成功,那麼提交,透過這樣的方式來保證原子性、一致性。所以,接下來將說明如何使用事務。
一、透過命令列方式使用事務成功進入mysql命令列終端之後,執行命令begin來開始事務執行插入命令,往資料表寫入資料如果這時候發現插入資料不正確,那麼可以執行命令rollback回滾如果確認資料沒問題,那麼執行命令commit提交事務二、採用C++方式使用事務首先初始化連線資料庫控制代碼,連線資料庫,並設定不自動提交事務然後執行插入資料,如果插入失敗或者出錯,那麼執行回滾事務函式,如果成功,那麼執行提交事務函式最後完成操作之後,關閉資料庫控制代碼三、總結mysql事務可以用來維護資料庫的完整性,確保執行插入、更新、刪除語句的時候,要麼全部執行,要麼全部不執行。
-
4 # 技術分享realize
Mysql事務一般處理複雜資料,進行操作的過程中,如果出錯,那麼回滾,如果成功,那麼提交,透過這樣的方式來保證原子性、一致性。所以,接下來將說明如何使用事務。
一、透過命令列方式使用事務成功進入mysql命令列終端之後,執行命令begin來開始事務執行插入命令,往資料表寫入資料如果這時候發現插入資料不正確,那麼可以執行命令rollback回滾如果確認資料沒問題,那麼執行命令commit提交事務二、採用C++方式使用事務首先初始化連線資料庫控制代碼,連線資料庫,並設定不自動提交事務然後執行插入資料,如果插入失敗或者出錯,那麼執行回滾事務函式,如果成功,那麼執行提交事務函式最後完成操作之後,關閉資料庫控制代碼三、總結mysql事務可以用來維護資料庫的完整性,確保執行插入、更新、刪除語句的時候,要麼全部執行,要麼全部不執行。
提到事務,你肯定不陌生,和資料庫打交道的時候,我們總是會用到事務。最經典的例子就是轉賬,你要給朋友小王轉100塊錢,而此時你的銀行卡只有100塊錢。
轉賬過程具體到程式裡會有一系列的操作,比如查詢餘額、做加減法、更新餘額等,這些操作必須保證是一體的,不然等程式查完之後,還沒做減法之前,你這100塊錢,完全可以藉著這個時間差再查一次,然後再給另外一個朋友轉賬,如果銀行這麼整,不就亂了麼?這時就要用到“事務”這個概念了。
簡單來說,事務就是要保證一組資料庫操作,要麼全部成功,要麼全部失敗。在MySQL中,事務支援是在引擎層實現的。你現在知道,MySQL是一個支援多引擎的系統,但並不是所有的引擎都支援事務。比如MySQL原生的MyISAM引擎就不支援事務,這也是MyISAM被InnoDB取代的重要原因之一。
今天的文章裡,我將會以InnoDB為例,剖析MySQL在事務支援方面的特定實現,並基於原理給出相應的實踐建議,希望這些案例能加深你對MySQL事務原理的理解。
隔離性與隔離級別提到事務,你肯定會想到ACID(Atomicity、Consistency、Isolation、Durability,即原子性、一致性、隔離性、永續性),今天我們就來說說其中I,也就是“隔離性”。
當資料庫上有多個事務同時執行的時候,就可能出現髒讀(dirty read)、不可重複讀(non-repeatable read)、幻讀(phantom read)的問題,為了解決這些問題,就有了“隔離級別”的概念。
在談隔離級別之前,你首先要知道,你隔離得越嚴實,效率就會越低。因此很多時候,我們都要在二者之間尋找一個平衡點。SQL標準的事務隔離級別包括:讀未提交(read uncommitted)、讀提交(read committed)、可重複讀(repeatable read)和序列化(serializable )。下面我逐一為你解釋:
讀未提交是指,一個事務還沒提交時,它做的變更就能被別的事務看到。讀提交是指,一個事務提交之後,它做的變更才會被其他事務看到。可重複讀是指,一個事務執行過程中看到的資料,總是跟這個事務在啟動時看到的資料是一致的。當然在可重複讀隔離級別下,未提交變更對其他事務也是不可見的。序列化,顧名思義是對於同一行記錄,“寫”會加“寫鎖”,“讀”會加“讀鎖”。當出現讀寫鎖衝突的時候,後訪問的事務必須等前一個事務執行完成,才能繼續執行。其中“讀提交”和“可重複讀”比較難理解,所以我用一個例子說明這幾種隔離級別。假設資料表T中只有一列,其中一行的值為1,下面是按照時間順序執行兩個事務的行為。
mysql> create table T(c int) engine=InnoDB; insert into T(c) values(1);
我們來看看在不同的隔離級別下,事務A會有哪些不同的返回結果,也就是圖裡面V1、V2、V3的返回值分別是什麼。
若隔離級別是“讀未提交”, 則V1的值就是2。這時候事務B雖然還沒有提交,但是結果已經被A看到了。因此,V2、V3也都是2。若隔離級別是“讀提交”,則V1是1,V2的值是2。事務B的更新在提交後才能被A看到。所以, V3的值也是2。若隔離級別是“可重複讀”,則V1、V2是1,V3是2。之所以V2還是1,遵循的就是這個要求:事務在執行期間看到的資料前後必須是一致的。若隔離級別是“序列化”,則在事務B執行“將1改成2”的時候,會被鎖住。直到事務A提交後,事務B才可以繼續執行。所以從A的角度看, V1、V2值是1,V3的值是2。在實現上,資料庫裡面會建立一個檢視,訪問的時候以檢視的邏輯結果為準。在“可重複讀”隔離級別下,這個檢視是在事務啟動時建立的,整個事務存在期間都用這個檢視。在“讀提交”隔離級別下,這個檢視是在每個SQL語句開始執行的時候建立的。這裡需要注意的是,“讀未提交”隔離級別下直接返回記錄上的最新值,沒有檢視概念;而“序列化”隔離級別下直接用加鎖的方式來避免並行訪問。
我們可以看到在不同的隔離級別下,資料庫行為是有所不同的。Oracle資料庫的預設隔離級別其實就是“讀提交”,因此對於一些從Oracle遷移到MySQL的應用,為保證資料庫隔離級別的一致,你一定要記得將MySQL的隔離級別設定為“讀提交”。
配置的方式是,將啟動引數transaction-isolation的值設定成READ-COMMITTED。你可以用show variables來檢視當前的值。
mysql> show variables like "transaction_isolation"; +-----------------------+----------------+ | Variable_name | Value | +-----------------------+----------------+ | transaction_isolation | READ-COMMITTED | +-----------------------+----------------+
總結來說,存在即合理,哪個隔離級別都有它自己的使用場景,你要根據自己的業務情況來定。我想你可能會問那什麼時候需要“可重複讀”的場景呢?我們來看一個數據校對邏輯的案例。
假設你在管理一個個人銀行賬戶表。一個表存了每個月月底的餘額,一個表存了賬單明細。這時候你要做資料校對,也就是判斷上個月的餘額和當前餘額的差額,是否與本月的賬單明細一致。你一定希望在校對過程中,即使有使用者發生了一筆新的交易,也不影響你的校對結果。
這時候使用“可重複讀”隔離級別就很方便。事務啟動時的檢視可以認為是靜態的,不受其他事務更新的影響。
事務隔離的實現理解了事務的隔離級別,我們再來看看事務隔離具體是怎麼實現的。這裡我們展開說明“可重複讀”。
在MySQL中,實際上每條記錄在更新的時候都會同時記錄一條回滾操作。記錄上的最新值,透過回滾操作,都可以得到前一個狀態的值。
假設一個值從1被按順序改成了2、3、4,在回滾日誌裡面就會有類似下面的記錄。
當前值是4,但是在查詢這條記錄的時候,不同時刻啟動的事務會有不同的read-view。如圖中看到的,在檢視A、B、C裡面,這一個記錄的值分別是1、2、4,同一條記錄在系統中可以存在多個版本,就是資料庫的多版本併發控制(MVCC)。對於read-view A,要得到1,就必須將當前值依次執行圖中所有的回滾操作得到。
同時你會發現,即使現在有另外一個事務正在將4改成5,這個事務跟read-view A、B、C對應的事務是不會衝突的。
什麼時候才不需要了呢?就是當系統裡沒有比這個回滾日誌更早的read-view的時候。
長事務意味著系統裡面會存在很老的事務檢視。由於這些事務隨時可能訪問資料庫裡面的任何資料,所以這個事務提交之前,資料庫裡面它可能用到的回滾記錄都必須保留,這就會導致大量佔用儲存空間。
在MySQL 5.5及以前的版本,回滾日誌是跟資料字典一起放在ibdata檔案裡的,即使長事務最終提交,回滾段被清理,檔案也不會變小。我見過資料只有20GB,而回滾段有200GB的庫。最終只好為了清理回滾段,重建整個庫。
除了對回滾段的影響,長事務還佔用鎖資源,也可能拖垮整個庫,這個我們會在後面講鎖的時候展開。
事務的啟動方式如前面所述,長事務有這些潛在風險,我當然是建議你儘量避免。其實很多時候業務開發同學並不是有意使用長事務,通常是由於誤用所致。MySQL的事務啟動方式有以下幾種:
顯式啟動事務語句, begin 或 start transaction。配套的提交語句是commit,回滾語句是rollback。set autocommit=0,這個命令會將這個執行緒的自動提交關掉。意味著如果你只執行一個select語句,這個事務就啟動了,而且並不會自動提交。這個事務持續存在直到你主動執行commit 或 rollback 語句,或者斷開連線。有些客戶端連線框架會預設連線成功後先執行一個set autocommit=0的命令。這就導致接下來的查詢都在事務中,如果是長連線,就導致了意外的長事務。
因此,我會建議你總是使用set autocommit=1, 透過顯式語句的方式來啟動事務。
但是有的開發同學會糾結“多一次互動”的問題。對於一個需要頻繁使用事務的業務,第二種方式每個事務在開始時都不需要主動執行一次 “begin”,減少了語句的互動次數。如果你也有這個顧慮,我建議你使用commit work and chain語法。
在autocommit為1的情況下,用begin顯式啟動的事務,如果執行commit則提交事務。如果執行 commit work and chain,則是提交事務並自動啟動下一個事務,這樣也省去了再次執行begin語句的開銷。同時帶來的好處是從程式開發的角度明確地知道每個語句是否處於事務中。
你可以在information_schema庫的innodb_trx這個表中查詢長事務,比如下面這個語句,用於查詢持續時間超過60s的事務。
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60