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

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

創(chuàng)新互聯(lián)是專業(yè)的尼元陽網(wǎng)站建設(shè)公司，尼元陽接單;提供網(wǎng)站設(shè)計制作、網(wǎng)站設(shè)計,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進行尼元陽網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團隊,希望更多企業(yè)前來合作!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

上面的begin/commit為事務(wù)的開始和結(jié)束，因為在前一步我們關(guān)閉了mysql的autocommit，所以需要手動控制事務(wù)的提交。

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

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

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

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

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

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

3、 select * from t_items where name='手機' for update;

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

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

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

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

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

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

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

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

修改不同數(shù)據(jù)庫的隔離級別

查看隔離級別

設(shè)置隔離界別

隔離級別=Read Uncommitted、read committed、Repeatable read、Serializable

注：SQL server只能改當前會話，不能改全局。

查詢鎖表

查詢死鎖語句

查看當前事務(wù)的隔離級別

設(shè)置當前事務(wù)的隔離級別

隔離級別=Read Uncommitted、read committed、Repeatable read、Serializable

MySQL默認：REPEATABLE READ

查看隔離級別

設(shè)置當前一個事務(wù)的隔離級別

設(shè)置整個會話的隔離級別：

MYSQL的事務(wù)隔離級別，MVCC，readView和版本鏈小結(jié)

MVCC(Mutil-Version Concurrency Control)，就是多版本并發(fā)控制。這種并發(fā)控制的方法，主要應(yīng)用在RC和RR隔離級別的事務(wù)當中，利用執(zhí)行select操作時，訪問記錄版本鏈，使得不同事物的讀寫，寫讀可以并發(fā)執(zhí)行，提高系統(tǒng)性能。

Innodb 有兩個隱藏字段 trx_id(事務(wù)id)和roll_pointer(回滾指針)。

transaction id ：

innoDB里面每個事務(wù)有一個唯一的事務(wù)ID，叫作transaction id，它是在事務(wù)開始的時候向InnoDB的事務(wù)系統(tǒng)申請的，是按申請順序嚴格遞增的。

roll_pointer ：

指向上一事務(wù)版本的指針。

版本鏈 ：

是一個單鏈表結(jié)構(gòu)，對于同一行數(shù)據(jù)，每一個事務(wù)對其進行更新的時候都會產(chǎn)生一個新的版本，就會存儲在這個鏈表當中。

一個存儲事務(wù)id的列表。

readview的幾個參數(shù)：

m_ids:表示活躍事務(wù)id列表

min_trx_id:活躍事務(wù)中的最小事務(wù)id

max_trx_id:已創(chuàng)建的最大事務(wù)id

creator_trx_id:當前的事務(wù)id。

readview的生成時機：

RC隔離級別：每次讀取數(shù)據(jù)前，都生成一個readview；

RR隔離級別：在第一次讀取數(shù)據(jù)前，生成一個readview；

使用場景：

[ 創(chuàng)建事務(wù)節(jié)點 ] 當我創(chuàng)建一個新的事務(wù)需要讀取一行數(shù)據(jù), 我會查詢活躍的事務(wù)列表; 假設(shè)我當前的事務(wù)id是200, 當前活躍的事務(wù)id沒有我的200, 因此需要去拷貝一個最新的不活躍事務(wù)并在版本鏈最后插入一個新節(jié)點200; mysql會去對比版本鏈和readView, 假設(shè)版本鏈數(shù)據(jù)為[1,50,100,150], 活躍列表為[100,150], 說明100和150都是未提交的活躍事務(wù), 再向前一個節(jié)點50不在活躍事務(wù)列表說明事務(wù)50已經(jīng)提交, 所以事務(wù)200拷貝事務(wù)50并插入版本鏈最后, 且將200追加到readView活躍列表的最后一個元素

[ 使用事務(wù)節(jié)點 ] 當我再次進行200號事務(wù)的查詢或修改, 我需要讀版本鏈的數(shù)據(jù), 因為上一次操作已經(jīng)在版本鏈做了200號節(jié)點, 因此我讀的數(shù)據(jù)都是200號節(jié)點的數(shù)據(jù), 這樣就隔離了其他未提交的事務(wù); 我的全部增刪查改都在200號版本鏈上進行

[ readView實現(xiàn)事務(wù)隔離級別 ]以上兩點都是基于隔離級別"讀已提交"來進行說明的; 當mysql設(shè)置為"可重復(fù)讀"時, 不同事務(wù)仍然是保存在版本鏈的不同節(jié)點上, 只不過新的事務(wù)創(chuàng)建的時候拷貝了當下的readView列表, 只要新事物不提交就一直使用這個拷貝的活躍列表; 假設(shè)此時100號數(shù)據(jù)提交了, 我在新事務(wù)執(zhí)行了select 會去查活躍列表發(fā)現(xiàn)100號事務(wù)還是未提交狀態(tài), 因此讀取到的還是50號事務(wù)提交的記錄。

原子性，一致性，隔離性，持久性。

未提交讀（read uncommitted）、提交讀（read committed）、可重復(fù)讀（repeatable read）、序列化讀（serializable）

如何查看mysql數(shù)據(jù)庫隔離級別

修改方法

有兩種方法可以對配置了 systemd 的程序進行資源隔離：1. 命令行修改：通過執(zhí)行?systemctl set-property?命令實現(xiàn)，形式為?systemctl set-property?name parameter=value；修改默認即時生效。2. 手工修改文件：直接編輯程序的 systemd unit file 文件，完成之后需手工執(zhí)行?systemctl?daemon-reload?更新配置，并重啟服務(wù)?systemctl restart name.service。

systemd unit file 里支持的資源隔離配置項，如常見的：

CPUQuota=value

該參數(shù)表示服務(wù)可以獲取的最大 CPU 時間，value 為百分數(shù)形式，高于 100% 表示可使用?1 核以上的?CPU。與 cgroup cpu 控制器?cpu.cfs_quota_us?配置項對應(yīng)。

MemoryLimit=value

該參數(shù)表示服務(wù)可以使用的最大內(nèi)存量，value 可以使用 K, M, G, T 等后綴表示值的大小。與 cgroup?memory 控制器?memory.limit_in_bytes?配置項對應(yīng)。

事務(wù)的4種隔離級別

READ UNCOMMITTED ? ? ? 未提交讀，可以讀取未提交的數(shù)據(jù)。

READ COMMITTED ? ? ? ? 已提交讀，對于鎖定讀(select with for update 或者 for share)、update 和 delete 語句，InnoDB 僅鎖定索引記錄，而不鎖定它們之間的間隙，因此允許在鎖定的記錄旁邊自由插入新記錄。 ? ? ? ? ? ? ? ? ? ?

Gap locking 僅用于外鍵約束檢查和重復(fù)鍵檢查。

REPEATABLE READ ? ? ? ?可重復(fù)讀，事務(wù)中的一致性讀取讀取的是事務(wù)第一次讀取所建立的快照。

SERIALIZABLE ? ? ? ? ? 序列化在了解了 4 種隔離級別的需求后，在采用鎖控制隔離級別的基礎(chǔ)上，我們需要了解加鎖的對象(數(shù)據(jù)本身間隙)，以及了解整個數(shù)據(jù)范圍的全集組成。

數(shù)據(jù)范圍全集組成

SQL 語句根據(jù)條件判斷不需要掃描的數(shù)據(jù)范圍（不加鎖）；

SQL 語句根據(jù)條件掃描到的可能需要加鎖的數(shù)據(jù)范圍；

以單個數(shù)據(jù)范圍為例，數(shù)據(jù)范圍全集包含：（數(shù)據(jù)范圍不一定是連續(xù)的值，也可能是間隔的值組成）

mysql隔離級別

MySQL 中事務(wù)的隔離級別一共分為四種，分別如下：

序列化（SERIALIZABLE）：如果隔離級別為序列化，則用戶之間通過一個接一個順序地執(zhí)行當前的事務(wù)，這種隔離級別提供了事務(wù)之間最大限度的隔離。

可重復(fù)讀（REPEATABLE READ）：在可重復(fù)讀在這一隔離級別上，事務(wù)不會被看成是一個序列。不過，當前正在執(zhí)行事務(wù)的變化仍然不能被外部看到，也就是說，如果用戶在另外一個事務(wù)中執(zhí)行同條 SELECT 語句數(shù)次，結(jié)果總是相同的。（因為正在執(zhí)行的事務(wù)所產(chǎn)生的數(shù)據(jù)變化不能被外部看到）。

提交讀（READ COMMITTED）：READ COMMITTED 隔離級別的安全性比 REPEATABLE READ 隔離級別的安全性要差。處于 READ COMMITTED 級別的事務(wù)可以看到其他事務(wù)對數(shù)據(jù)的修改。也就是說，在事務(wù)處理期間，如果其他事務(wù)修改了相應(yīng)的表，那么同一個事務(wù)的多個 SELECT 語句可能返回不同的結(jié)果。

未提交讀（READ UNCOMMITTED）：READ UNCOMMITTED 提供了事務(wù)之間最小限度的隔離。除了容易產(chǎn)生虛幻的讀操作和不能重復(fù)的讀操作外，處于這個隔離級的事務(wù)可以讀到其他事務(wù)還沒有提交的數(shù)據(jù)，如果這個事務(wù)使用其他事務(wù)不提交的變化作為計算的基礎(chǔ)，然后那些未提交的變化被它們的父事務(wù)撤銷，這就導致了大量的數(shù)據(jù)變化。

應(yīng)用環(huán)境

與其他的大型數(shù)據(jù)庫例如?Oracle、DB2、SQL Server等相比，MySQL自有它的不足之處，但是這絲毫也沒有減少它受歡迎的程度。對于一般的個人使用者和中小型企業(yè)來說，MySQL提供的功能已經(jīng)綽綽有余，而且由于 MySQL是開放源碼軟件，因此可以大大降低總體擁有成本。

MySQL 事務(wù)的默認隔離級別是什么？可以解決幻讀問題么？

我們設(shè)想一個場景，這個場景中我們需要插入多條相關(guān)聯(lián)的數(shù)據(jù)到數(shù)據(jù)庫，不幸的是，這個過程可能會遇到下面這些問題：

上面的任何一個問題都可能會導致數(shù)據(jù)的不一致性。為了保證數(shù)據(jù)的一致性，系統(tǒng)必須能夠處理這些問題。事務(wù)就是我們抽象出來簡化這些問題的首選機制。事務(wù)的概念起源于數(shù)據(jù)庫，目前，已經(jīng)成為一個比較廣泛的概念。

何為事務(wù)？ 一言蔽之， 事務(wù)是邏輯上的一組操作，要么都執(zhí)行，要么都不執(zhí)行。

事務(wù)最經(jīng)典也經(jīng)常被拿出來說例子就是轉(zhuǎn)賬了。假如小明要給小紅轉(zhuǎn)賬 1000 元，這個轉(zhuǎn)賬會涉及到兩個關(guān)鍵操作，這兩個操作必須都成功或者都失敗。

事務(wù)會把這兩個操作就可以看成邏輯上的一個整體，這個整體包含的操作要么都成功，要么都要失敗。這樣就不會出現(xiàn)小明余額減少而小紅的余額卻并沒有增加的情況。

大多數(shù)情況下，我們在談?wù)撌聞?wù)的時候，如果沒有特指 分布式事務(wù) ，往往指的就是 數(shù)據(jù)庫事務(wù) 。

數(shù)據(jù)庫事務(wù)在我們?nèi)粘ｉ_發(fā)中接觸的最多了。如果你的項目屬于單體架構(gòu)的話，你接觸到的往往就是數(shù)據(jù)庫事務(wù)了。

那數(shù)據(jù)庫事務(wù)有什么作用呢？

簡單來說，數(shù)據(jù)庫事務(wù)可以保證多個對數(shù)據(jù)庫的操作（也就是 SQL 語句）構(gòu)成一個邏輯上的整體。構(gòu)成這個邏輯上的整體的這些數(shù)據(jù)庫操作遵循： 要么全部執(zhí)行成功,要么全部不執(zhí)行 。

另外，關(guān)系型數(shù)據(jù)庫（例如： MySQL 、 SQL Server 、 Oracle 等）事務(wù)都有 ACID 特性：

ACID

這里要額外補充一點： 只有保證了事務(wù)的持久性、原子性、隔離性之后，一致性才能得到保障。也就是說 A、I、D 是手段，C 是目的！

在典型的應(yīng)用程序中，多個事務(wù)并發(fā)運行，經(jīng)常會操作相同的數(shù)據(jù)來完成各自的任務(wù)（多個用戶對同一數(shù)據(jù)進行操作）。并發(fā)雖然是必須的，但可能會導致以下的問題。

不可重復(fù)讀和幻讀區(qū)別 ：不可重復(fù)讀的重點是修改比如多次讀取一條記錄發(fā)現(xiàn)其中某些列的值被修改，幻讀的重點在于新增或者刪除比如多次查詢同一條查詢語句（DQL）時，記錄發(fā)現(xiàn)記錄增多或減少了。

SQL 標準定義了四個隔離級別：

隔離級別臟讀不可重復(fù)讀幻讀 READ-UNCOMMITTED READ-COMMITTED REPEATABLE-READ SERIALIZABLE

MySQL 的隔離級別基于鎖和 MVCC 機制共同實現(xiàn)的。

SERIALIZABLE 隔離級別，是通過鎖來實現(xiàn)的。除了 SERIALIZABLE 隔離級別，其他的隔離級別都是基于 MVCC 實現(xiàn)。

不過， SERIALIZABLE 之外的其他隔離級別可能也需要用到鎖機制，就比如 REPEATABLE-READ 在當前讀情況下需要使用加鎖讀來保證不會出現(xiàn)幻讀。

MySQL InnoDB 存儲引擎的默認支持的隔離級別是 REPEATABLE-READ（可重讀） 。我們可以通過 SELECT @@tx_isolation; 命令來查看，MySQL 8.0 該命令改為 SELECT @@transaction_isolation;

從上面對 SQL 標準定義了四個隔離級別的介紹可以看出，標準的 SQL 隔離級別定義里，REPEATABLE-READ(可重復(fù)讀)是不可以防止幻讀的。

但是！InnoDB 實現(xiàn)的 REPEATABLE-READ 隔離級別其實是可以解決幻讀問題發(fā)生的，主要有下面兩種情況：

因為隔離級別越低，事務(wù)請求的鎖越少，所以大部分數(shù)據(jù)庫系統(tǒng)的隔離級別都是 READ-COMMITTED ，但是你要知道的是 InnoDB 存儲引擎默認使用 REPEATABLE-READ 并不會有任何性能損失。

InnoDB 存儲引擎在分布式事務(wù)的情況下一般會用到 SERIALIZABLE 隔離級別。

當前名稱：mysql怎么查隔離級別 怎么看數(shù)據(jù)庫的隔離級別
文章轉(zhuǎn)載：http://aaarwkj.com/article24/docpdje.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、網(wǎng)站設(shè)計公司、手機網(wǎng)站建設(shè)、微信小程序、品牌網(wǎng)站建設(shè)、網(wǎng)站策劃

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)