mysql的事務(wù)四個(gè)特性以及事務(wù)的四個(gè)隔離級(jí)別

分別是原子性、一致性、隔離性、持久性。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專(zhuān)注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、成都微信小程序、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了米脂免費(fèi)建站歡迎大家使用！

原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫(kù)，如果操作失敗則不能對(duì)數(shù)據(jù)庫(kù)有任何影響。

一致性是指事務(wù)必須使數(shù)據(jù)庫(kù)從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)，也就是說(shuō)一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。舉例來(lái)說(shuō)，假設(shè)用戶A和用戶B兩者的錢(qián)加起來(lái)一共是1000，那么不管A和B之間如何轉(zhuǎn)賬、轉(zhuǎn)幾次賬，事務(wù)結(jié)束后兩個(gè)用戶的錢(qián)相加起來(lái)應(yīng)該還得是1000，這就是事務(wù)的一致性。

隔離性是當(dāng)多個(gè)用戶并發(fā)訪問(wèn)數(shù)據(jù)庫(kù)時(shí)，比如同時(shí)操作同一張表時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開(kāi)啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。關(guān)于事務(wù)的隔離性數(shù)據(jù)庫(kù)提供了多種隔離級(jí)別，稍后會(huì)介紹到。

持久性是指一個(gè)事務(wù)一旦被提交了，那么對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫(kù)系統(tǒng)遇到故障的情況下也不會(huì)丟失提交事務(wù)的操作。例如我們?cè)谑褂肑DBC操作數(shù)據(jù)庫(kù)時(shí)，在提交事務(wù)方法后，提示用戶事務(wù)操作完成，當(dāng)我們程序執(zhí)行完成直到看到提示后，就可以認(rèn)定事務(wù)已經(jīng)正確提交，即使這時(shí)候數(shù)據(jù)庫(kù)出現(xiàn)了問(wèn)題，也必須要將我們的事務(wù)完全執(zhí)行完成。否則的話就會(huì)造成我們雖然看到提示事務(wù)處理完畢，但是數(shù)據(jù)庫(kù)因?yàn)楣收隙鴽](méi)有執(zhí)行事務(wù)的重大錯(cuò)誤。這是不允許的。

在數(shù)據(jù)庫(kù)操作中，在并發(fā)的情況下可能出現(xiàn)如下問(wèn)題：

正是為了解決以上情況，數(shù)據(jù)庫(kù)提供了幾種隔離級(jí)別。

數(shù)據(jù)庫(kù)事務(wù)的隔離級(jí)別有4個(gè)，由低到高依次為Read uncommitted(未授權(quán)讀取、讀未提交)、Read committed（授權(quán)讀取、讀提交）、Repeatable read（可重復(fù)讀?。?、Serializable（序列化），這四個(gè)級(jí)別可以逐個(gè)解決臟讀、不可重復(fù)讀、幻象讀這幾類(lèi)問(wèn)題。

雖然數(shù)據(jù)庫(kù)的隔離級(jí)別可以解決大多數(shù)問(wèn)題，但是靈活度較差，為此又提出了悲觀鎖和樂(lè)觀鎖的概念。

悲觀鎖，它指的是對(duì)數(shù)據(jù)被外界（包括本系統(tǒng)當(dāng)前的其他事務(wù)，以及來(lái)自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度。因此，在整個(gè)數(shù)據(jù)處理過(guò)程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實(shí)現(xiàn)，往往依靠數(shù)據(jù)庫(kù)提供的鎖機(jī)制。也只有數(shù)據(jù)庫(kù)層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問(wèn)的排他性，否則，即使在本系統(tǒng)的數(shù)據(jù)訪問(wèn)層中實(shí)現(xiàn)了加鎖機(jī)制，也無(wú)法保證外部系統(tǒng)不會(huì)修改數(shù)據(jù)。

商品t_items表中有一個(gè)字段status，status為1代表商品未被下單，status為2代表商品已經(jīng)被下單（此時(shí)該商品無(wú)法再次下單），那么我們對(duì)某個(gè)商品下單時(shí)必須確保該商品status為1。假設(shè)商品的id為1。

如果不采用鎖，那么操作方法如下：

但是上面這種場(chǎng)景在高并發(fā)訪問(wèn)的情況下很可能會(huì)出現(xiàn)問(wèn)題。例如當(dāng)?shù)谝徊讲僮髦校樵?xún)出來(lái)的商品status為1。但是當(dāng)我們執(zhí)行第三步Update操作的時(shí)候，有可能出現(xiàn)其他人先一步對(duì)商品下單把t_items中的status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個(gè)商品被下單2次，使得數(shù)據(jù)不一致。所以說(shuō)這種方式是不安全的。

在上面的場(chǎng)景中，商品信息從查詢(xún)出來(lái)到修改，中間有一個(gè)處理訂單的過(guò)程，使用悲觀鎖的原理就是，當(dāng)我們?cè)诓樵?xún)出t_items信息后就把當(dāng)前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個(gè)過(guò)程中，因?yàn)閠_items被鎖定了，就不會(huì)出現(xiàn)有第三者來(lái)對(duì)其進(jìn)行修改了。需要注意的是，要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫(kù)的自動(dòng)提交屬性，因?yàn)镸ySQL默認(rèn)使用autocommit模式，也就是說(shuō)，當(dāng)你執(zhí)行一個(gè)更新操作后，MySQL會(huì)立刻將結(jié)果進(jìn)行提交。我們可以使用命令設(shè)置MySQL為非autocommit模式： set autocommit=0;

設(shè)置完autocommit后，我們就可以執(zhí)行我們的正常業(yè)務(wù)了。具體如下：

上面的begin/commit為事務(wù)的開(kāi)始和結(jié)束，因?yàn)樵谇耙徊轿覀冴P(guān)閉了mysql的autocommit，所以需要手動(dòng)控制事務(wù)的提交。

上面的第一步我們執(zhí)行了一次查詢(xún)操作： select status from t_items where id=1 for update; 與普通查詢(xún)不一樣的是，我們使用了 select…for update 的方式，這樣就通過(guò)數(shù)據(jù)庫(kù)實(shí)現(xiàn)了悲觀鎖。此時(shí)在t_items表中，id為1的那條數(shù)據(jù)就被我們鎖定了，其它的事務(wù)必須等本次事務(wù)提交之后才能執(zhí)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會(huì)被其它事務(wù)修改。需要注意的是，在事務(wù)中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個(gè)數(shù)據(jù)時(shí)才會(huì)等待其它事務(wù)結(jié)束后才執(zhí)行，一般 SELECT ... 則不受此影響。拿上面的實(shí)例來(lái)說(shuō)，當(dāng)我執(zhí)行 select status from t_items where id=1 for update; 后。我在另外的事務(wù)中如果再次執(zhí)行 select status from t_items where id=1 for update; 則第二個(gè)事務(wù)會(huì)一直等待第一個(gè)事務(wù)的提交，此時(shí)第二個(gè)查詢(xún)處于阻塞的狀態(tài)，但是如果我是在第二個(gè)事務(wù)中執(zhí)行 select status from t_items where id=1; 則能正常查詢(xún)出數(shù)據(jù)，不會(huì)受第一個(gè)事務(wù)的影響。

使用 select…for update 會(huì)把數(shù)據(jù)給鎖住，不過(guò)我們需要注意一些鎖的級(jí)別，MySQL InnoDB默認(rèn)Row-Level Lock，所以只有「明確」地指定主鍵或者索引，MySQL 才會(huì)執(zhí)行Row lock (只鎖住被選取的數(shù)據(jù)) ，否則MySQL 將會(huì)執(zhí)行Table Lock (將整個(gè)數(shù)據(jù)表單給鎖住)。舉例如下：

1、 select * from t_items where id=1 for update;

這條語(yǔ)句明確指定主鍵（id=1），并且有此數(shù)據(jù)（id=1的數(shù)據(jù)存在），則采用row lock。只鎖定當(dāng)前這條數(shù)據(jù)。

2、 select * from t_items where id=3 for update;

這條語(yǔ)句明確指定主鍵，但是卻查無(wú)此數(shù)據(jù)，此時(shí)不會(huì)產(chǎn)生lock（沒(méi)有元數(shù)據(jù)，又去lock誰(shuí)呢？）。

3、 select * from t_items where name='手機(jī)' for update;

這條語(yǔ)句沒(méi)有指定數(shù)據(jù)的主鍵，那么此時(shí)產(chǎn)生table lock，即在當(dāng)前事務(wù)提交前整張數(shù)據(jù)表的所有字段將無(wú)法被查詢(xún)。

4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; （注：在SQL中表示不等于）

上述兩條語(yǔ)句的主鍵都不明確，也會(huì)產(chǎn)生table lock。

5、 select * from t_items where status=1 for update; （假設(shè)為status字段添加了索引）

這條語(yǔ)句明確指定了索引，并且有此數(shù)據(jù)，則產(chǎn)生row lock。

6、 select * from t_items where status=3 for update; （假設(shè)為status字段添加了索引）

這條語(yǔ)句明確指定索引，但是根據(jù)索引查無(wú)此數(shù)據(jù)，也就不會(huì)產(chǎn)生lock。

樂(lè)觀鎖（ Optimistic Locking ） 相對(duì)悲觀鎖而言，樂(lè)觀鎖假設(shè)認(rèn)為數(shù)據(jù)一般情況下不會(huì)造成沖突，所以只會(huì)在數(shù)據(jù)進(jìn)行提交更新的時(shí)候，才會(huì)正式對(duì)數(shù)據(jù)的沖突與否進(jìn)行檢測(cè)，如果發(fā)現(xiàn)沖突了，則返回用戶錯(cuò)誤的信息，讓用戶決定如何去做。實(shí)現(xiàn)樂(lè)觀鎖一般來(lái)說(shuō)有以下2種方式：

Mysql數(shù)據(jù)庫(kù)中，事務(wù)是指什么？如何使用該功能？

什么是事務(wù)？ \x0d\x0a\x0d\x0a事務(wù)是邏輯上的一組操作，組成這組操作的各個(gè)單元，要不全都成功要不全都失敗，這個(gè)特性就是事務(wù) \x0d\x0a\x0d\x0a注意：mysql數(shù)據(jù)支持事務(wù)，但是要求必須是innoDB存儲(chǔ)引擎 \x0d\x0a\x0d\x0a解決這個(gè)問(wèn)題： \x0d\x0a\x0d\x0amysql的事務(wù)解決這個(gè)問(wèn)題，因?yàn)閙ysql的事務(wù)特性，要求這組操作，要不全都成功，要不全都失敗，這樣就避免了某個(gè)操作成功某個(gè)操作失敗。利于數(shù)據(jù)的安全 \x0d\x0a\x0d\x0a如何使用： \x0d\x0a\x0d\x0a（1）在執(zhí)行sql語(yǔ)句之前，我們要開(kāi)啟事務(wù) start transaction; \x0d\x0a\x0d\x0a（2）正常執(zhí)行我們的sql語(yǔ)句 \x0d\x0a\x0d\x0a（3）當(dāng)sql語(yǔ)句執(zhí)行完畢，存在兩種情況： \x0d\x0a\x0d\x0a1，全都成功，我們要將sql語(yǔ)句對(duì)數(shù)據(jù)庫(kù)造成的影響提交到數(shù)據(jù)庫(kù)中，committ \x0d\x0a\x0d\x0a2，某些sql語(yǔ)句失敗，我們執(zhí)行rollback（回滾），將對(duì)數(shù)據(jù)庫(kù)操作趕緊撤銷(xiāo) \x0d\x0a\x0d\x0a（注意：mysql數(shù)據(jù)支持事務(wù)，但是要求必須是innoDB存儲(chǔ)引擎） \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------沒(méi)有成功“回滾”執(zhí)行rollback \x0d\x0amysql start transaction; //開(kāi)啟事務(wù) \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; //只要有一個(gè)不成功，執(zhí)行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------成功之后 進(jìn)行commit操作 \x0d\x0amysql start transaction; //開(kāi)啟事務(wù) \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; //兩個(gè)都成功后執(zhí)行commit（只要不執(zhí)行commit，sql語(yǔ)句不會(huì)對(duì)真實(shí)的數(shù)據(jù)庫(kù)造成影響） \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 事務(wù)和鎖

當(dāng)多個(gè)用戶訪問(wèn)同一份數(shù)據(jù)時(shí)，一個(gè)用戶在更改數(shù)據(jù)的過(guò)程中，可能有其他用戶同時(shí)發(fā)起更改請(qǐng)求，為保證數(shù)據(jù)庫(kù)記錄的更新從一個(gè)一致性狀態(tài)變?yōu)榱硗庖粋€(gè)一致性狀態(tài)，使用事務(wù)處理是非常必要的，事務(wù)具有以下四個(gè)特性：

MySQL 提供了多種事務(wù)型存儲(chǔ)引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事務(wù)。為了支持事務(wù)，InnoDB 存儲(chǔ)引擎引入了與事務(wù)處理相關(guān)的 REDO 日志和 UNDO 日志，同時(shí)事務(wù)依賴(lài)于 MySQL 提供的鎖機(jī)制

事務(wù)執(zhí)行時(shí)需要將執(zhí)行的事務(wù)日志寫(xiě)入日志文件，對(duì)應(yīng)的文件為 REDO 日志。當(dāng)每條 SQL 進(jìn)行數(shù)據(jù)更新操作時(shí)，首先將 REDO 日志寫(xiě)進(jìn)日志緩沖區(qū)。當(dāng)客戶端執(zhí)行 COMMIT 命令提交時(shí)，日志緩沖區(qū)的內(nèi)容將被刷新到磁盤(pán)，日志緩沖區(qū)的刷新方式或者時(shí)間間隔可以通過(guò)參數(shù) innodb_flush_log_at_trx_commit 控制

REDO 日志對(duì)應(yīng)磁盤(pán)上的 ib_logifleN 文件，該文件默認(rèn)為 5MB，建議設(shè)置為 512MB，以便容納較大的事務(wù)。MySQL 崩潰恢復(fù)時(shí)會(huì)重新執(zhí)行 REDO 日志的記錄，恢復(fù)最新數(shù)據(jù)，保證已提交事務(wù)的持久性

與 REDO 日志相反，UNDO 日志主要用于事務(wù)異常時(shí)的數(shù)據(jù)回滾，具體內(nèi)容就是記錄數(shù)據(jù)被修改前的信息到 UNDO 緩沖區(qū)，然后在合適的時(shí)間將內(nèi)容刷新到磁盤(pán)

假如由于系統(tǒng)錯(cuò)誤或者 rollback 操作而導(dǎo)致事務(wù)回滾，可以根據(jù) undo 日志回滾到?jīng)]修改前的狀態(tài)，保證未提交事務(wù)的原子性

與 REDO 日志不同的是，磁盤(pán)上不存在單獨(dú)的 UNDO 日志文件，所有的 UNDO 日志均存在表空間對(duì)應(yīng)的 .ibd 數(shù)據(jù)文件中，即使 MySQL 服務(wù)啟動(dòng)了獨(dú)立表空間

在 MySQL 中，可以使用 BEGIN 開(kāi)始事務(wù)，使用 COMMIT 結(jié)束事務(wù)，中間可以使用 ROLLBACK 回滾事務(wù)。MySQL 通過(guò) SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等語(yǔ)句支持本地事務(wù)

MySQL 定義了四種隔離級(jí)別，指定事務(wù)中哪些數(shù)據(jù)改變其他事務(wù)可見(jiàn)、哪些數(shù)據(jù)該表其他事務(wù)不可見(jiàn)。低級(jí)別的隔離級(jí)別可以支持更高的并發(fā)處理，同時(shí)占用的系統(tǒng)資源更少

InnoDB 系統(tǒng)級(jí)事務(wù)隔離級(jí)別可以使用以下語(yǔ)句設(shè)置：

查看系統(tǒng)級(jí)事務(wù)隔離級(jí)別：

InnoDB 會(huì)話級(jí)事務(wù)隔離級(jí)別可以使用以下語(yǔ)句設(shè)置：

查看會(huì)話級(jí)事務(wù)隔離級(jí)別：

在該隔離級(jí)別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。讀取未提交的數(shù)據(jù)稱(chēng)為臟讀（Dirty Read），即是：首先開(kāi)啟 A 和 B 兩個(gè)事務(wù)，在 B 事務(wù)更新但未提交之前，A 事務(wù)讀取到了更新后的數(shù)據(jù)，但由于 B 事務(wù)回滾，導(dǎo)致 A 事務(wù)出現(xiàn)了臟讀現(xiàn)象

所有事務(wù)只能看見(jiàn)已經(jīng)提交事務(wù)所做的改變，此級(jí)別可以解決臟讀，但也會(huì)導(dǎo)致不可重復(fù)讀（Nonrepeatable Read）：首先開(kāi)啟 A 和 B 兩個(gè)事務(wù)，A事務(wù)讀取了 B 事務(wù)的數(shù)據(jù)，在 B 事務(wù)更新并提交后，A 事務(wù)又讀取到了更新后的數(shù)據(jù)，此時(shí)就出現(xiàn)了同一 A 事務(wù)中的查詢(xún)出現(xiàn)了不同的查詢(xún)結(jié)果

MySQL 默認(rèn)的事務(wù)隔離級(jí)別，能確保同一事務(wù)的多個(gè)實(shí)例在并發(fā)讀取數(shù)據(jù)時(shí)看到同樣的數(shù)據(jù)行，理論上會(huì)導(dǎo)致一個(gè)問(wèn)題，幻讀（Phontom Read）。例如，第一個(gè)事務(wù)對(duì)一個(gè)表中的數(shù)據(jù)做了修改，這種修改會(huì)涉及表中的全部數(shù)據(jù)行，同時(shí)第二個(gè)事務(wù)也修改這個(gè)表中的數(shù)據(jù)，這次的修改是向表中插入一行新數(shù)據(jù)，此時(shí)就會(huì)發(fā)生操作第一個(gè)事務(wù)的用戶發(fā)現(xiàn)表中還有沒(méi)有修改的數(shù)據(jù)行

InnoDB 通過(guò)多版本并發(fā)控制機(jī)制（MVCC）解決了該問(wèn)題：InnoDB 通過(guò)為每個(gè)數(shù)據(jù)行增加兩個(gè)隱含值的方式來(lái)實(shí)現(xiàn)，這兩個(gè)隱含值記錄了行的創(chuàng)建時(shí)間、過(guò)期時(shí)間以及每一行存儲(chǔ)時(shí)間發(fā)生時(shí)的系統(tǒng)版本號(hào)，每個(gè)查詢(xún)根據(jù)事務(wù)的版本號(hào)來(lái)查詢(xún)結(jié)果

通過(guò)強(qiáng)制事務(wù)排序，使其不可能相互沖突，從而解決幻讀問(wèn)題。簡(jiǎn)而言之，就是在每個(gè)讀的數(shù)據(jù)行上加上共享鎖實(shí)現(xiàn)，這個(gè)級(jí)別會(huì)導(dǎo)致大量的超時(shí)現(xiàn)象和鎖競(jìng)爭(zhēng)，一般不推薦使用

為了解決數(shù)據(jù)庫(kù)并發(fā)控制問(wèn)題，如走到同一時(shí)刻客戶端對(duì)同一張表做更新或者查詢(xún)操作，需要對(duì)并發(fā)操作進(jìn)行控制，因此產(chǎn)生了鎖

共享鎖的粒度是行或者元組（多個(gè)行），一個(gè)事務(wù)獲取了共享鎖以后，可以對(duì)鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行讀操作

排他鎖的粒度與共享鎖相同，一個(gè)事務(wù)獲取排他鎖以后，可以對(duì)鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行寫(xiě)操作

有兩個(gè)事務(wù) A 和 B，如果事務(wù) A 獲取了一個(gè)元組的共享鎖，事務(wù) B 還可以立即獲取這個(gè)元組的共享鎖，但不能獲取這個(gè)元組的排他鎖，必須等到事務(wù) A 釋放共享鎖之后。如果事務(wù) A 獲取了一個(gè)元組的排他鎖，事務(wù) B 不能立即獲取這個(gè)元組的共享鎖，也不能立即獲取這個(gè)元組的排他鎖，必須等到 A 釋放排他鎖之后

意向鎖是一種表鎖，鎖定的粒度是整張表，分為意向共享鎖和意向排他鎖。意向共享鎖表示一個(gè)事務(wù)有意對(duì)數(shù)據(jù)上共享鎖或者排他鎖。有意表示事務(wù)想執(zhí)行操作但還沒(méi)真正執(zhí)行

鎖的粒度主要分為表鎖和行鎖

表鎖的開(kāi)銷(xiāo)最小，同時(shí)允許的并發(fā)量也是最小。MyISAM 存儲(chǔ)引擎使用該鎖機(jī)制。當(dāng)要寫(xiě)入數(shù)據(jù)時(shí)，整個(gè)表記錄被鎖，此時(shí)其他讀/寫(xiě)動(dòng)作一律等待。一些特定的動(dòng)作，如 ALTER TABLE 執(zhí)行時(shí)使用的也是表鎖

行鎖可以支持最大的并發(fā)，InnoDB 存儲(chǔ)引擎使用該鎖機(jī)制。如果要支持并發(fā)讀/寫(xiě)，建議采用 InnoDB 存儲(chǔ)引擎

mysql數(shù)據(jù)庫(kù) 事務(wù)提交怎么處理

1.普通事務(wù)

以 begin / start transaction 開(kāi)始，commit / rollback 結(jié)束的事務(wù)?；蛘呤菐в斜４纥c(diǎn) savepoint 的事務(wù)。

2. 鏈?zhǔn)绞聞?wù)

一個(gè)事務(wù)在提交的時(shí)候自動(dòng)將上下文傳給下一個(gè)事務(wù)，也就是說(shuō)一個(gè)事務(wù)的提交和下一個(gè)事務(wù)的開(kāi)始是原子性的，下一個(gè)事務(wù)可以看到上一個(gè)事務(wù)的處理結(jié)果。MySQL 的鏈?zhǔn)绞聞?wù)靠參數(shù) completion_type 控制，并且回滾和提交的語(yǔ)句后面加上 work 關(guān)鍵詞。

3. 嵌套事務(wù)

有多個(gè) begin / commit / rollback 這樣的事務(wù)塊的事務(wù)，并且有父子關(guān)系。子事務(wù)的提交完成后不會(huì)真的提交，而是等到父事務(wù)提交才真正的提交。

4. 自治事務(wù)

內(nèi)部事務(wù)的提交不隨外部事務(wù)的影響，一般用作記錄內(nèi)部事務(wù)的異常情況。MySQL 不支持自治事務(wù)，但是某些場(chǎng)景可以用 MySQL 的插件式引擎來(lái)變相實(shí)現(xiàn)。

MySql之commit、rollback等事務(wù)控制命令

MYSQL 事務(wù)處理主要有兩種方法

1、用 begin, rollback, commit 來(lái)實(shí)現(xiàn)

begin 或/ start transaction )開(kāi)始一個(gè)事務(wù)

rollback 事務(wù)回滾

commit 事務(wù)確認(rèn)

2、直接用 SET 來(lái)改變 MySQL 的自動(dòng)提交模式:

set autocommit=0 禁止自動(dòng)提交

set autocommit=1 開(kāi)啟自動(dòng)提交

1.不管 autocommit 是1還是0

start transaction 后，只有當(dāng) commit 數(shù)據(jù)才會(huì)生效， rollback 后就會(huì)回滾。

2、當(dāng) autocommit 為 0 時(shí)

不管有沒(méi)有 start transaction .

只有當(dāng) commit 數(shù)據(jù)才會(huì)生效， rollback 后就會(huì)回滾。

3、如果 autocommit 為1 ，并且沒(méi)有 start transaction .

調(diào)用 rollback 是沒(méi)有用的。因?yàn)槭聞?wù)已經(jīng)自動(dòng)提交了。

事務(wù)測(cè)試1

事務(wù)測(cè)試2

flag 相當(dāng)一定義這個(gè)保存點(diǎn)的名字

savepoint flag : savepoint 允許在事務(wù)中創(chuàng)建一個(gè)保存點(diǎn)，一個(gè)事務(wù)中可以有多個(gè)savepoint ；

release savepoint flag :刪除一個(gè)事務(wù)的保存點(diǎn)，當(dāng)沒(méi)有指定的保存點(diǎn)時(shí)，執(zhí)行該語(yǔ)句會(huì)拋出一個(gè)異常；

rollback to flag :把事務(wù)回滾到標(biāo)記點(diǎn)；

set transaction :用來(lái)設(shè)置事務(wù)的隔離級(jí)別。InnoDB存儲(chǔ)引擎提供事務(wù)的隔離級(jí)別有

READ UNCOMMITTED 、 READ COMMITTED 、 REPEATABLE READ 和 SERIALIZABLE

select @@transaction_isolation;

SELECT @@SESSION.transaction_isolation, @@SESSION.transaction_read_only;