欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

MySQL四種事務(wù)隔離級(jí)別詳解

 更新時(shí)間:2020年07月31日 09:23:27   作者:花弄影  
這篇文章主要為大家詳細(xì)介紹了MySQL四種事務(wù)隔離級(jí)別的相關(guān)資料,文中示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下

本文實(shí)驗(yàn)的測(cè)試環(huán)境:Windows 10+cmd+MySQL5.6.36+InnoDB

一、事務(wù)的基本要素(ACID)

  1、原子性(Atomicity):事務(wù)開(kāi)始后所有操作,要么全部做完,要么全部不做,不可能停滯在中間環(huán)節(jié)。事務(wù)執(zhí)行過(guò)程中出錯(cuò),會(huì)回滾到事務(wù)開(kāi)始前的狀態(tài),所有的操作就像沒(méi)有發(fā)生一樣。也就是說(shuō)事務(wù)是一個(gè)不可分割的整體,就像化學(xué)中學(xué)過(guò)的原子,是物質(zhì)構(gòu)成的基本單位。

   2、一致性(Consistency):事務(wù)開(kāi)始前和結(jié)束后,數(shù)據(jù)庫(kù)的完整性約束沒(méi)有被破壞 。比如A向B轉(zhuǎn)賬,不可能A扣了錢,B卻沒(méi)收到。

   3、隔離性(Isolation):同一時(shí)間,只允許一個(gè)事務(wù)請(qǐng)求同一數(shù)據(jù),不同的事務(wù)之間彼此沒(méi)有任何干擾。比如A正在從一張銀行卡中取錢,在A取錢的過(guò)程結(jié)束前,B不能向這張卡轉(zhuǎn)賬。

   4、持久性(Durability):事務(wù)完成后,事務(wù)對(duì)數(shù)據(jù)庫(kù)的所有更新將被保存到數(shù)據(jù)庫(kù),不能回滾。

  小結(jié):原子性是事務(wù)隔離的基礎(chǔ),隔離性和持久性是手段,最終目的是為了保持?jǐn)?shù)據(jù)的一致性。

二、事務(wù)的并發(fā)問(wèn)題

  1、臟讀:事務(wù)A讀取了事務(wù)B更新的數(shù)據(jù),然后B回滾操作,那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)

  2、不可重復(fù)讀:事務(wù) A 多次讀取同一數(shù)據(jù),事務(wù) B 在事務(wù)A多次讀取的過(guò)程中,對(duì)數(shù)據(jù)作了更新并提交,導(dǎo)致事務(wù)A多次讀取同一數(shù)據(jù)時(shí),結(jié)果 不一致。

  3、幻讀:系統(tǒng)管理員A將數(shù)據(jù)庫(kù)中所有學(xué)生的成績(jī)從具體分?jǐn)?shù)改為ABCDE等級(jí),但是系統(tǒng)管理員B就在這個(gè)時(shí)候插入了一條具體分?jǐn)?shù)的記錄,當(dāng)系統(tǒng)管理員A改結(jié)束后發(fā)現(xiàn)還有一條記錄沒(méi)有改過(guò)來(lái),就好像發(fā)生了幻覺(jué)一樣,這就叫幻讀。

  小結(jié):不可重復(fù)讀的和幻讀很容易混淆,不可重復(fù)讀側(cè)重于修改,幻讀側(cè)重于新增或刪除。解決不可重復(fù)讀的問(wèn)題只需鎖住滿足條件的行,解決幻讀需要鎖表

四、用例子說(shuō)明各個(gè)隔離級(jí)別的情況

1、讀未提交:

(1)打開(kāi)一個(gè)客戶端A,并設(shè)置當(dāng)前事務(wù)模式為read uncommitted(未提交讀),查詢表account的初始值:

(2)在客戶端A的事務(wù)提交之前,打開(kāi)另一個(gè)客戶端B,更新表account:

(3)這時(shí),雖然客戶端B的事務(wù)還沒(méi)提交,但是客戶端A就可以查詢到B已經(jīng)更新的數(shù)據(jù):

(4)一旦客戶端B的事務(wù)因?yàn)槟撤N原因回滾,所有的操作都將會(huì)被撤銷,那客戶端A查詢到的數(shù)據(jù)其實(shí)就是臟數(shù)據(jù):

(5)在客戶端A執(zhí)行更新語(yǔ)句update account set balance = balance - 50 where id =1,lilei的balance沒(méi)有變成350,居然是400,是不是很奇怪,數(shù)據(jù)的一致性沒(méi)問(wèn)啊,如果你這么想就太天真 了,在應(yīng)用程序中,我們會(huì)用400-50=350,并不知道其他會(huì)話回滾了,要想解決這個(gè)問(wèn)題可以采用讀已提交的隔離級(jí)別

2、讀已提交

(1)打開(kāi)一個(gè)客戶端A,并設(shè)置當(dāng)前事務(wù)模式為read committed(未提交讀),查詢表account的初始值:

(2)在客戶端A的事務(wù)提交之前,打開(kāi)另一個(gè)客戶端B,更新表account:

(3)這時(shí),客戶端B的事務(wù)還沒(méi)提交,客戶端A不能查詢到B已經(jīng)更新的數(shù)據(jù),解決了臟讀問(wèn)題:

(4)客戶端B的事務(wù)提交

(5)客戶端A執(zhí)行與上一步相同的查詢,結(jié)果與上一步不一致,即產(chǎn)生了不可重復(fù)讀的問(wèn)題,在應(yīng)用程序中,假設(shè)我們處于客戶端A的會(huì)話,查詢到lilei的balance為450,但是其他事務(wù)將lilei的balance值改為400,我們并不知道,如果用450這個(gè)值去做其他操作,是有問(wèn)題的,不過(guò)這個(gè)概率真的很小哦,要想避免這個(gè)問(wèn)題,可以采用可重復(fù)讀的隔離級(jí)別

3、可重復(fù)讀

(1)打開(kāi)一個(gè)客戶端A,并設(shè)置當(dāng)前事務(wù)模式為repeatable read,查詢表account的初始值:

(2)在客戶端A的事務(wù)提交之前,打開(kāi)另一個(gè)客戶端B,更新表account并提交,客戶端B的事務(wù)居然可以修改客戶端A事務(wù)查詢到的行,也就是mysql的可重復(fù)讀不會(huì)鎖住事務(wù)查詢到的行,這一點(diǎn)出乎我的意料,sql標(biāo)準(zhǔn)中事務(wù)隔離級(jí)別為可重復(fù)讀時(shí),讀寫操作要鎖行的,mysql居然沒(méi)有鎖,我了個(gè)去。在應(yīng)用程序中要注意給行加鎖,不然你會(huì)以步驟(1)中l(wèi)ilei的balance為400作為中間值去做其他操作

(3)在客戶端A執(zhí)行步驟(1)的查詢:

(4)執(zhí)行步驟(1),lilei的balance仍然是400與步驟(1)查詢結(jié)果一致,沒(méi)有出現(xiàn)不可重復(fù)讀的 問(wèn)題;接著執(zhí)行update balance = balance - 50 where id = 1,balance沒(méi)有變成400-50=350,lilei的balance值用的是步驟(2)中的350來(lái)算的,所以是300,數(shù)據(jù)的一致性倒是沒(méi)有被破壞,這個(gè)有點(diǎn)神奇,也許是mysql的特色吧

mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 400 |
| 2 | hanmei | 16000 |
| 3 | lucy | 2400 |
+------+--------+---------+
rows in set (0.00 sec)

mysql> update account set balance = balance - 50 where id = 1;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0

mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 300 |
| 2 | hanmei | 16000 |
| 3 | lucy | 2400 |
+------+--------+---------+
rows in set (0.00 sec)

(5) 在客戶端A開(kāi)啟事務(wù),查詢表account的初始值

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 300 |
| 2 | hanmei | 16000 |
| 3 | lucy | 2400 |
+------+--------+---------+
rows in set (0.00 sec)

(6)在客戶端B開(kāi)啟事務(wù),新增一條數(shù)據(jù),其中balance字段值為600,并提交

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(4,'lily',600);
Query OK, 1 row affected (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.01 sec)

(7) 在客戶端A計(jì)算balance之和,值為300+16000+2400=18700,沒(méi)有把客戶端B的值算進(jìn)去,客戶端A提交后再計(jì)算balance之和,居然變成了19300,這是因?yàn)榘芽蛻舳薆的600算進(jìn)去了,站在客戶的角度,客戶是看不到客戶端B的,它會(huì)覺(jué)得是天下掉餡餅了,多了600塊,這就是幻讀,站在開(kāi)發(fā)者的角度,數(shù)據(jù)的 一致性并沒(méi)有破壞。但是在應(yīng)用程序中,我們得代碼可能會(huì)把18700提交給用戶了,如果你一定要避免這情況小概率狀況的發(fā)生,那么就要采取下面要介紹的事務(wù)隔離級(jí)別“串行化”

mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 18700 |
+--------------+
1 row in set (0.00 sec)

mysql> commit;
Query OK, 0 rows affected (0.00 sec)

mysql> select sum(balance) from account;
+--------------+
| sum(balance) |
+--------------+
| 19300 |
+--------------+
1 row in set (0.00 sec)

4.串行化

(1)打開(kāi)一個(gè)客戶端A,并設(shè)置當(dāng)前事務(wù)模式為serializable,查詢表account的初始值:

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> select * from account;
+------+--------+---------+
| id | name | balance |
+------+--------+---------+
| 1 | lilei | 10000 |
| 2 | hanmei | 10000 |
| 3 | lucy | 10000 |
| 4 | lily | 10000 |
+------+--------+---------+
rows in set (0.00 sec)

(2)打開(kāi)一個(gè)客戶端B,并設(shè)置當(dāng)前事務(wù)模式為serializable,插入一條記錄報(bào)錯(cuò),表被鎖了插入失敗,mysql中事務(wù)隔離級(jí)別為serializable時(shí)會(huì)鎖表,因此不會(huì)出現(xiàn)幻讀的情況,這種隔離級(jí)別并發(fā)性極低,往往一個(gè)事務(wù)霸占了一張表,其他成千上萬(wàn)個(gè)事務(wù)只有干瞪眼,得等他用完提交才可以使用,開(kāi)發(fā)中很少會(huì)用到。

mysql> set session transaction isolation level serializable;
Query OK, 0 rows affected (0.00 sec)

mysql> start transaction;
Query OK, 0 rows affected (0.00 sec)

mysql> insert into account values(5,'tom',0);
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction

補(bǔ)充: 

1、SQL規(guī)范所規(guī)定的標(biāo)準(zhǔn),不同的數(shù)據(jù)庫(kù)具體的實(shí)現(xiàn)可能會(huì)有些差異

2、mysql中默認(rèn)事務(wù)隔離級(jí)別是可重復(fù)讀時(shí)并不會(huì)鎖住讀取到的行

3、事務(wù)隔離級(jí)別為串行化時(shí),讀取數(shù)據(jù)會(huì)鎖住整張表

4、閱讀此文時(shí),如果站在開(kāi)發(fā)者的角度,也許會(huì)覺(jué)得不可重復(fù)讀和幻讀,在邏輯上并沒(méi)有什么問(wèn)題,最終數(shù)據(jù)仍然是一致的,但是站在用戶的角度,他們通常只能看到一個(gè)事務(wù)(只能看到客戶端A,不知道客戶端B這個(gè)臥底的存在),而不會(huì)考慮事務(wù)并發(fā)執(zhí)行的現(xiàn)象,一旦出現(xiàn)同一數(shù)據(jù)多次讀取結(jié)果不同,或者憑空出現(xiàn)新記錄,他們可能會(huì)產(chǎn)生疑慮,這是用戶體驗(yàn)的問(wèn)題。

5.事務(wù)在mysql中執(zhí)行時(shí),最終的結(jié)果不會(huì)出現(xiàn)數(shù)據(jù)的一致性的問(wèn)題,因?yàn)樵谝粋€(gè)事務(wù)中,mysql執(zhí)行某個(gè)操作未必會(huì)使用前一個(gè)操作的中間結(jié)果,它會(huì)根據(jù)其他并發(fā)事務(wù)的實(shí)際情況采來(lái)處理,看起來(lái)不合邏輯,但是保證了數(shù)據(jù)的一致性 ;但是事務(wù)在應(yīng)用程序中執(zhí)行時(shí),一個(gè)操作的結(jié)果會(huì)被下一個(gè)操作用到,并進(jìn)行其他的計(jì)算。這是我們得小心,可重復(fù)讀的時(shí)候應(yīng)該鎖行,串行化時(shí) 要鎖表,不然會(huì)破壞數(shù)據(jù)的一致性。

6、事務(wù)在mysql中執(zhí)行時(shí),mysql會(huì)根據(jù)各個(gè)事務(wù)的實(shí)際情況綜合處理,導(dǎo)致數(shù)據(jù)的一致性沒(méi)有被破壞,但是應(yīng)用程序時(shí)按照邏輯套路來(lái)出牌,并沒(méi)有mysql聰明,難免會(huì)出現(xiàn)數(shù)據(jù)的一致性問(wèn)題。

7、隔離級(jí)別越高,越能保證數(shù)據(jù)的完整性和一致性,但是對(duì)并發(fā)性能的影響也越大,魚和熊掌不可兼得啊。對(duì)于多數(shù)應(yīng)用程序,可以優(yōu)先考慮把數(shù)據(jù)庫(kù)系統(tǒng)的隔離級(jí)別設(shè)為Read Committed,它能夠避免臟讀取,而且具有較好的并發(fā)性能。盡管它會(huì)導(dǎo)致不可重復(fù)讀、幻讀這些并發(fā)問(wèn)題,在可能出現(xiàn)這類問(wèn)題的個(gè)別場(chǎng)合,可以由應(yīng)用程序采用悲觀鎖或樂(lè)觀鎖來(lái)控制。

以上就是本文的全部?jī)?nèi)容,希望對(duì)大家的學(xué)習(xí)有所幫助,也希望大家多多支持腳本之家。

相關(guān)文章

  • MySQL數(shù)據(jù)庫(kù)子查詢?sub?query

    MySQL數(shù)據(jù)庫(kù)子查詢?sub?query

    這篇文章主要介紹了MySQL數(shù)據(jù)庫(kù)子查詢?sub?query,子查詢指嵌套查詢下層的程序模塊,當(dāng)一個(gè)查詢是另一個(gè)查詢的條件的時(shí)候,更多相關(guān)內(nèi)容需要的小伙伴可以參考一下下面文章內(nèi)容介紹
    2022-06-06
  • MySQL深分頁(yè),limit 100000,10優(yōu)化方式

    MySQL深分頁(yè),limit 100000,10優(yōu)化方式

    MySQL中深分頁(yè)查詢因需掃描大量數(shù)據(jù)行導(dǎo)致效率低下,優(yōu)化方法包括子查詢優(yōu)化、延遲關(guān)聯(lián)、標(biāo)簽記錄法和使用between...and...等,通過(guò)減少回表次數(shù)和范圍掃描提升查詢性能,覆蓋索引幫助減少搜索次數(shù),提升性能
    2024-10-10
  • 最全的mysql查詢語(yǔ)句整理

    最全的mysql查詢語(yǔ)句整理

    這篇文章主要介紹了最全的mysql查詢語(yǔ)句整理,需要的朋友可以參考下
    2016-06-06
  • mysql unique option prefix myisam_recover instead of myisam-recover-options的解決方法

    mysql unique option prefix myisam_recover instead of myisam-

    Using unique option prefix myisam_recover instead of myisam-recover-options is deprecated and will be removed in a future release. Please use the full name instead
    2016-05-05
  • mysql ERROR 1045 (28000)問(wèn)題的解決方法

    mysql ERROR 1045 (28000)問(wèn)題的解決方法

    這篇文章主要介紹了mysql ERROR 1045 (28000)問(wèn)題的解決方法,文中步驟介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下
    2019-10-10
  • MySQL遷移中explicit_defaults_for_timestamp參數(shù)影響

    MySQL遷移中explicit_defaults_for_timestamp參數(shù)影響

    在MySQL數(shù)據(jù)庫(kù)遷移過(guò)程中,explicit_defaults_for_timestamp參數(shù)設(shè)置為off可能導(dǎo)致數(shù)據(jù)寫入行為變化,本文就來(lái)介紹一下explicit_defaults_for_timestamp參數(shù)影響,感興趣的可以了解一下
    2024-09-09
  • MySQL錯(cuò)誤代碼:1052?Column?'xxx'?in?field?list?is?ambiguous的原因和解決

    MySQL錯(cuò)誤代碼:1052?Column?'xxx'?in?field?list?is

    今天在工作中寫sql語(yǔ)句時(shí)遇到了個(gè)sql錯(cuò)誤,為記錄并不再重復(fù)出錯(cuò),下面這篇文章主要給大家介紹了關(guān)于MySQL錯(cuò)誤代碼:1052?Column?'xxx'?in?field?list?is?ambiguous的原因和解決方法,需要的朋友可以參考下
    2023-04-04
  • MySQL數(shù)據(jù)庫(kù)遭到攻擊篡改(使用備份和binlog進(jìn)行數(shù)據(jù)恢復(fù))

    MySQL數(shù)據(jù)庫(kù)遭到攻擊篡改(使用備份和binlog進(jìn)行數(shù)據(jù)恢復(fù))

    這篇文章主要介紹了MySQL數(shù)據(jù)庫(kù)遭到攻擊篡改(使用備份和binlog進(jìn)行數(shù)據(jù)恢復(fù)),需要的朋友可以參考下
    2016-04-04
  • mysql之過(guò)濾分組的具體實(shí)現(xiàn)

    mysql之過(guò)濾分組的具體實(shí)現(xiàn)

    在MySQL中過(guò)濾分組數(shù)據(jù)通常使用GROUP BY結(jié)合HAVING子句和WHERE子句,文中通過(guò)示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來(lái)一起學(xué)習(xí)學(xué)習(xí)吧
    2024-08-08
  • DBeaver如何實(shí)現(xiàn)導(dǎo)入excel中的大量數(shù)據(jù)

    DBeaver如何實(shí)現(xiàn)導(dǎo)入excel中的大量數(shù)據(jù)

    使用DBeaver導(dǎo)入Excel數(shù)據(jù)需先將文件轉(zhuǎn)換為CSV格式,詳細(xì)步驟包括:將Excel文件另存為CSV,確保列名與數(shù)據(jù)庫(kù)表字段對(duì)應(yīng),然后在DBeaver中創(chuàng)建表和導(dǎo)入CSV文件,注意選擇正確的編碼格式以防中文亂碼
    2024-10-10

最新評(píng)論