分別是原子性、一致性、隔離性、持久性。
網站建設哪家好,找成都創新互聯公司!專注于網頁設計、網站建設、微信開發、成都微信小程序、集團企業網站建設等服務項目。為回饋新老客戶創新互聯還提供了米脂免費建站歡迎大家使用!
原子性是指事務包含的所有操作要么全部成功,要么全部失敗回滾,因此事務的操作如果成功就必須要完全應用到數據庫,如果操作失敗則不能對數據庫有任何影響。
一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態,也就是說一個事務執行之前和執行之后都必須處于一致性狀態。舉例來說,假設用戶A和用戶B兩者的錢加起來一共是1000,那么不管A和B之間如何轉賬、轉幾次賬,事務結束后兩個用戶的錢相加起來應該還得是1000,這就是事務的一致性。
隔離性是當多個用戶并發訪問數據庫時,比如同時操作同一張表時,數據庫為每一個用戶開啟的事務,不能被其他事務的操作所干擾,多個并發事務之間要相互隔離。關于事務的隔離性數據庫提供了多種隔離級別,稍后會介紹到。
持久性是指一個事務一旦被提交了,那么對數據庫中的數據的改變就是永久性的,即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。例如我們在使用JDBC操作數據庫時,在提交事務方法后,提示用戶事務操作完成,當我們程序執行完成直到看到提示后,就可以認定事務已經正確提交,即使這時候數據庫出現了問題,也必須要將我們的事務完全執行完成。否則的話就會造成我們雖然看到提示事務處理完畢,但是數據庫因為故障而沒有執行事務的重大錯誤。這是不允許的。
在數據庫操作中,在并發的情況下可能出現如下問題:
正是為了解決以上情況,數據庫提供了幾種隔離級別。
數據庫事務的隔離級別有4個,由低到高依次為Read uncommitted(未授權讀取、讀未提交)、Read committed(授權讀取、讀提交)、Repeatable read(可重復讀?。erializable(序列化),這四個級別可以逐個解決臟讀、不可重復讀、幻象讀這幾類問題。
雖然數據庫的隔離級別可以解決大多數問題,但是靈活度較差,為此又提出了悲觀鎖和樂觀鎖的概念。
悲觀鎖,它指的是對數據被外界(包括本系統當前的其他事務,以及來自外部系統的事務處理)修改持保守態度。因此,在整個數據處理過程中,將數據處于鎖定狀態。悲觀鎖的實現,往往依靠數據庫提供的鎖機制。也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性,否則,即使在本系統的數據訪問層中實現了加鎖機制,也無法保證外部系統不會修改數據。
商品t_items表中有一個字段status,status為1代表商品未被下單,status為2代表商品已經被下單(此時該商品無法再次下單),那么我們對某個商品下單時必須確保該商品status為1。假設商品的id為1。
如果不采用鎖,那么操作方法如下:
但是上面這種場景在高并發訪問的情況下很可能會出現問題。例如當第一步操作中,查詢出來的商品status為1。但是當我們執行第三步Update操作的時候,有可能出現其他人先一步對商品下單把t_items中的status修改為2了,但是我們并不知道數據已經被修改了,這樣就可能造成同一個商品被下單2次,使得數據不一致。所以說這種方式是不安全的。
在上面的場景中,商品信息從查詢出來到修改,中間有一個處理訂單的過程,使用悲觀鎖的原理就是,當我們在查詢出t_items信息后就把當前的數據鎖定,直到我們修改完畢后再解鎖。那么在這個過程中,因為t_items被鎖定了,就不會出現有第三者來對其進行修改了。需要注意的是,要使用悲觀鎖,我們必須關閉mysql數據庫的自動提交屬性,因為MySQL默認使用autocommit模式,也就是說,當你執行一個更新操作后,MySQL會立刻將結果進行提交。我們可以使用命令設置MySQL為非autocommit模式: set autocommit=0;
設置完autocommit后,我們就可以執行我們的正常業務了。具體如下:
上面的begin/commit為事務的開始和結束,因為在前一步我們關閉了mysql的autocommit,所以需要手動控制事務的提交。
上面的第一步我們執行了一次查詢操作: select status from t_items where id=1 for update; 與普通查詢不一樣的是,我們使用了 select…for update 的方式,這樣就通過數據庫實現了悲觀鎖。此時在t_items表中,id為1的那條數據就被我們鎖定了,其它的事務必須等本次事務提交之后才能執行。這樣我們可以保證當前的數據不會被其它事務修改。需要注意的是,在事務中,只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個數據時才會等待其它事務結束后才執行,一般 SELECT ... 則不受此影響。拿上面的實例來說,當我執行 select status from t_items where id=1 for update; 后。我在另外的事務中如果再次執行 select status from t_items where id=1 for update; 則第二個事務會一直等待第一個事務的提交,此時第二個查詢處于阻塞的狀態,但是如果我是在第二個事務中執行 select status from t_items where id=1; 則能正常查詢出數據,不會受第一個事務的影響。
使用 select…for update 會把數據給鎖住,不過我們需要注意一些鎖的級別,MySQL InnoDB默認Row-Level Lock,所以只有「明確」地指定主鍵或者索引,MySQL 才會執行Row lock (只鎖住被選取的數據) ,否則MySQL 將會執行Table Lock (將整個數據表單給鎖住)。舉例如下:
1、 select * from t_items where id=1 for update;
這條語句明確指定主鍵(id=1),并且有此數據(id=1的數據存在),則采用row lock。只鎖定當前這條數據。
2、 select * from t_items where id=3 for update;
這條語句明確指定主鍵,但是卻查無此數據,此時不會產生lock(沒有元數據,又去lock誰呢?)。
3、 select * from t_items where name='手機' for update;
這條語句沒有指定數據的主鍵,那么此時產生table lock,即在當前事務提交前整張數據表的所有字段將無法被查詢。
4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; (注:在SQL中表示不等于)
上述兩條語句的主鍵都不明確,也會產生table lock。
5、 select * from t_items where status=1 for update; (假設為status字段添加了索引)
這條語句明確指定了索引,并且有此數據,則產生row lock。
6、 select * from t_items where status=3 for update; (假設為status字段添加了索引)
這條語句明確指定索引,但是根據索引查無此數據,也就不會產生lock。
樂觀鎖( Optimistic Locking ) 相對悲觀鎖而言,樂觀鎖假設認為數據一般情況下不會造成沖突,所以只會在數據進行提交更新的時候,才會正式對數據的沖突與否進行檢測,如果發現沖突了,則返回用戶錯誤的信息,讓用戶決定如何去做。實現樂觀鎖一般來說有以下2種方式:
什么是事務? \x0d\x0a\x0d\x0a事務是邏輯上的一組操作,組成這組操作的各個單元,要不全都成功要不全都失敗,這個特性就是事務 \x0d\x0a\x0d\x0a注意:mysql數據支持事務,但是要求必須是innoDB存儲引擎 \x0d\x0a\x0d\x0a解決這個問題: \x0d\x0a\x0d\x0amysql的事務解決這個問題,因為mysql的事務特性,要求這組操作,要不全都成功,要不全都失敗,這樣就避免了某個操作成功某個操作失敗。利于數據的安全 \x0d\x0a\x0d\x0a如何使用: \x0d\x0a\x0d\x0a(1)在執行sql語句之前,我們要開啟事務 start transaction; \x0d\x0a\x0d\x0a(2)正常執行我們的sql語句 \x0d\x0a\x0d\x0a(3)當sql語句執行完畢,存在兩種情況: \x0d\x0a\x0d\x0a1,全都成功,我們要將sql語句對數據庫造成的影響提交到數據庫中,committ \x0d\x0a\x0d\x0a2,某些sql語句失敗,我們執行rollback(回滾),將對數據庫操作趕緊撤銷 \x0d\x0a\x0d\x0a(注意:mysql數據支持事務,但是要求必須是innoDB存儲引擎) \x0d\x0amysql create table bank(name varchar(20),money decimal(5,1))engine=innodb defau \x0d\x0alt charset=utf8; \x0d\x0a\x0d\x0amysql inset into bank values('shaotuo',1000),('laohu',5000); \x0d\x0a\x0d\x0amysql select*from bank; \x0d\x0a+---------+--------+ \x0d\x0a| name | money | \x0d\x0a+---------+--------+ \x0d\x0a| shaotuo | 1000.0 | \x0d\x0a| laohu | 5000.0 | \x0d\x0a+---------+--------+ \x0d\x0a\x0d\x0a------沒有成功“回滾”執行rollback \x0d\x0amysql start transaction; //開啟事務 \x0d\x0aQuery OK, 0 rows affected (0.00 sec) \x0d\x0a\x0d\x0amysql update bank set money=money+500 where name='shaotuo'; \x0d\x0aQuery OK, 1 row affected (0.00 sec) \x0d\x0aRows matched: 1 Changed: 1 Warnings: 0 \x0d\x0a\x0d\x0amysql update bank set moey=money-500 where name='laohu'; \x0d\x0aERROR 1054 (42S22): Unknown column 'moey' in 'field list' \x0d\x0amysql rollback; //只要有一個不成功,執行rollback操作 \x0d\x0aQuery OK, 0 rows affected (0.01 sec) \x0d\x0a\x0d\x0amysql select*from bank; \x0d\x0a+---------+--------+ \x0d\x0a| name | money | \x0d\x0a+---------+--------+ \x0d\x0a| shaotuo | 1000.0 | \x0d\x0a| laohu | 5000.0 | \x0d\x0a+---------+--------+ \x0d\x0a------成功之后 進行commit操作 \x0d\x0amysql start transaction; //開啟事務 \x0d\x0aQuery OK, 0 rows affected (0.00 sec) \x0d\x0a\x0d\x0amysql update bank set money=money+500 where name='shaotuo'; \x0d\x0aQuery OK, 1 row affected (0.01 sec) \x0d\x0aRows matched: 1 Changed: 1 Warnings: 0 \x0d\x0a\x0d\x0amysql update bank set money=money-500 where name='laohu'; \x0d\x0aQuery OK, 1 row affected (0.00 sec) \x0d\x0aRows matched: 1 Changed: 1 Warnings: 0 \x0d\x0a\x0d\x0amysql commit; //兩個都成功后執行commit(只要不執行commit,sql語句不會對真實的數據庫造成影響) \x0d\x0aQuery OK, 0 rows affected (0.05 sec) \x0d\x0a\x0d\x0amysql select*from bank; \x0d\x0a+---------+--------+ \x0d\x0a| name | money | \x0d\x0a+---------+--------+ \x0d\x0a| shaotuo | 1500.0 | \x0d\x0a| laohu | 4500.0 | \x0d\x0a+---------+--------+
當多個用戶訪問同一份數據時,一個用戶在更改數據的過程中,可能有其他用戶同時發起更改請求,為保證數據庫記錄的更新從一個一致性狀態變為另外一個一致性狀態,使用事務處理是非常必要的,事務具有以下四個特性:
MySQL 提供了多種事務型存儲引擎,如 InnoDB 和 BDB 等,而 MyISAM 不支持事務。為了支持事務,InnoDB 存儲引擎引入了與事務處理相關的 REDO 日志和 UNDO 日志,同時事務依賴于 MySQL 提供的鎖機制
事務執行時需要將執行的事務日志寫入日志文件,對應的文件為 REDO 日志。當每條 SQL 進行數據更新操作時,首先將 REDO 日志寫進日志緩沖區。當客戶端執行 COMMIT 命令提交時,日志緩沖區的內容將被刷新到磁盤,日志緩沖區的刷新方式或者時間間隔可以通過參數 innodb_flush_log_at_trx_commit 控制
REDO 日志對應磁盤上的 ib_logifleN 文件,該文件默認為 5MB,建議設置為 512MB,以便容納較大的事務。MySQL 崩潰恢復時會重新執行 REDO 日志的記錄,恢復最新數據,保證已提交事務的持久性
與 REDO 日志相反,UNDO 日志主要用于事務異常時的數據回滾,具體內容就是記錄數據被修改前的信息到 UNDO 緩沖區,然后在合適的時間將內容刷新到磁盤
假如由于系統錯誤或者 rollback 操作而導致事務回滾,可以根據 undo 日志回滾到沒修改前的狀態,保證未提交事務的原子性
與 REDO 日志不同的是,磁盤上不存在單獨的 UNDO 日志文件,所有的 UNDO 日志均存在表空間對應的 .ibd 數據文件中,即使 MySQL 服務啟動了獨立表空間
在 MySQL 中,可以使用 BEGIN 開始事務,使用 COMMIT 結束事務,中間可以使用 ROLLBACK 回滾事務。MySQL 通過 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等語句支持本地事務
MySQL 定義了四種隔離級別,指定事務中哪些數據改變其他事務可見、哪些數據該表其他事務不可見。低級別的隔離級別可以支持更高的并發處理,同時占用的系統資源更少
InnoDB 系統級事務隔離級別可以使用以下語句設置:
查看系統級事務隔離級別:
InnoDB 會話級事務隔離級別可以使用以下語句設置:
查看會話級事務隔離級別:
在該隔離級別,所有事務都可以看到其他未提交事務的執行結果。讀取未提交的數據稱為臟讀(Dirty Read),即是:首先開啟 A 和 B 兩個事務,在 B 事務更新但未提交之前,A 事務讀取到了更新后的數據,但由于 B 事務回滾,導致 A 事務出現了臟讀現象
所有事務只能看見已經提交事務所做的改變,此級別可以解決臟讀,但也會導致不可重復讀(Nonrepeatable Read):首先開啟 A 和 B 兩個事務,A事務讀取了 B 事務的數據,在 B 事務更新并提交后,A 事務又讀取到了更新后的數據,此時就出現了同一 A 事務中的查詢出現了不同的查詢結果
MySQL 默認的事務隔離級別,能確保同一事務的多個實例在并發讀取數據時看到同樣的數據行,理論上會導致一個問題,幻讀(Phontom Read)。例如,第一個事務對一個表中的數據做了修改,這種修改會涉及表中的全部數據行,同時第二個事務也修改這個表中的數據,這次的修改是向表中插入一行新數據,此時就會發生操作第一個事務的用戶發現表中還有沒有修改的數據行
InnoDB 通過多版本并發控制機制(MVCC)解決了該問題:InnoDB 通過為每個數據行增加兩個隱含值的方式來實現,這兩個隱含值記錄了行的創建時間、過期時間以及每一行存儲時間發生時的系統版本號,每個查詢根據事務的版本號來查詢結果
通過強制事務排序,使其不可能相互沖突,從而解決幻讀問題。簡而言之,就是在每個讀的數據行上加上共享鎖實現,這個級別會導致大量的超時現象和鎖競爭,一般不推薦使用
為了解決數據庫并發控制問題,如走到同一時刻客戶端對同一張表做更新或者查詢操作,需要對并發操作進行控制,因此產生了鎖
共享鎖的粒度是行或者元組(多個行),一個事務獲取了共享鎖以后,可以對鎖定范圍內的數據執行讀操作
排他鎖的粒度與共享鎖相同,一個事務獲取排他鎖以后,可以對鎖定范圍內的數據執行寫操作
有兩個事務 A 和 B,如果事務 A 獲取了一個元組的共享鎖,事務 B 還可以立即獲取這個元組的共享鎖,但不能獲取這個元組的排他鎖,必須等到事務 A 釋放共享鎖之后。如果事務 A 獲取了一個元組的排他鎖,事務 B 不能立即獲取這個元組的共享鎖,也不能立即獲取這個元組的排他鎖,必須等到 A 釋放排他鎖之后
意向鎖是一種表鎖,鎖定的粒度是整張表,分為意向共享鎖和意向排他鎖。意向共享鎖表示一個事務有意對數據上共享鎖或者排他鎖。有意表示事務想執行操作但還沒真正執行
鎖的粒度主要分為表鎖和行鎖
表鎖的開銷最小,同時允許的并發量也是最小。MyISAM 存儲引擎使用該鎖機制。當要寫入數據時,整個表記錄被鎖,此時其他讀/寫動作一律等待。一些特定的動作,如 ALTER TABLE 執行時使用的也是表鎖
行鎖可以支持最大的并發,InnoDB 存儲引擎使用該鎖機制。如果要支持并發讀/寫,建議采用 InnoDB 存儲引擎
1.普通事務
以 begin / start transaction 開始,commit / rollback 結束的事務?;蛘呤菐в斜4纥c savepoint 的事務。
2. 鏈式事務
一個事務在提交的時候自動將上下文傳給下一個事務,也就是說一個事務的提交和下一個事務的開始是原子性的,下一個事務可以看到上一個事務的處理結果。MySQL 的鏈式事務靠參數 completion_type 控制,并且回滾和提交的語句后面加上 work 關鍵詞。
3. 嵌套事務
有多個 begin / commit / rollback 這樣的事務塊的事務,并且有父子關系。子事務的提交完成后不會真的提交,而是等到父事務提交才真正的提交。
4. 自治事務
內部事務的提交不隨外部事務的影響,一般用作記錄內部事務的異常情況。MySQL 不支持自治事務,但是某些場景可以用 MySQL 的插件式引擎來變相實現。
MYSQL 事務處理主要有兩種方法
1、用 begin, rollback, commit 來實現
begin 或/ start transaction )開始一個事務
rollback 事務回滾
commit 事務確認
2、直接用 SET 來改變 MySQL 的自動提交模式:
set autocommit=0 禁止自動提交
set autocommit=1 開啟自動提交
1.不管 autocommit 是1還是0
start transaction 后,只有當 commit 數據才會生效, rollback 后就會回滾。
2、當 autocommit 為 0 時
不管有沒有 start transaction .
只有當 commit 數據才會生效, rollback 后就會回滾。
3、如果 autocommit 為1 ,并且沒有 start transaction .
調用 rollback 是沒有用的。因為事務已經自動提交了。
事務測試1
事務測試2
flag 相當一定義這個保存點的名字
savepoint flag : savepoint 允許在事務中創建一個保存點,一個事務中可以有多個savepoint ;
release savepoint flag :刪除一個事務的保存點,當沒有指定的保存點時,執行該語句會拋出一個異常;
rollback to flag :把事務回滾到標記點;
set transaction :用來設置事務的隔離級別。InnoDB存儲引擎提供事務的隔離級別有
READ UNCOMMITTED 、 READ COMMITTED 、 REPEATABLE READ 和 SERIALIZABLE
select @@transaction_isolation;
SELECT @@SESSION.transaction_isolation, @@SESSION.transaction_read_only;
文章題目:mysql怎么結束事務 mysql結束事務語句
分享路徑:http://vcdvsql.cn/article38/hehjsp.html
成都網站建設公司_創新互聯,為您提供網站制作、營銷型網站建設、面包屑導航、企業網站制作、網站收錄、網站策劃
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯