mysql的四大特性

1、原子性：在整個(gè)操作的事務(wù)中，要么全部成功，要么全部失敗。

創(chuàng)新互聯(lián)主營(yíng)新鄉(xiāng)縣網(wǎng)站建設(shè)的網(wǎng)絡(luò)公司,主營(yíng)網(wǎng)站建設(shè)方案,成都App定制開發(fā),新鄉(xiāng)縣h5微信小程序定制開發(fā)搭建,新鄉(xiāng)縣網(wǎng)站營(yíng)銷推廣歡迎新鄉(xiāng)縣等地區(qū)企業(yè)咨詢

2、隔離性：所謂隔離性，就是每個(gè)事務(wù)執(zhí)行的時(shí)候，相互之間不會(huì)受到影響，都是單獨(dú)的事務(wù)。

3、一致性：也就是說事務(wù)在執(zhí)行之后，必須和之前的數(shù)據(jù)保持一致。

4、持久性：事務(wù)一旦提交，就會(huì)持久化到數(shù)據(jù)庫(kù)中，不能回滾。

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

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

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

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

隔離性是當(dāng)多個(gè)用戶并發(fā)訪問數(shù)據(jù)庫(kù)時(shí)，比如同時(shí)操作同一張表時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開啟的事務(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ù)完全執(zhí)行完成。否則的話就會(huì)造成我們雖然看到提示事務(wù)處理完畢，但是數(shù)據(jù)庫(kù)因?yàn)楣收隙鴽]有執(zhí)行事務(wù)的重大錯(cuò)誤。這是不允許的。

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

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

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

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

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

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

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

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

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

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

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

上面的第一步我們執(zhí)行了一次查詢操作： select status from t_items where id=1 for update; 與普通查詢不一樣的是，我們使用了 select…for update 的方式，這樣就通過數(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í)例來說，當(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è)查詢處于阻塞的狀態(tài)，但是如果我是在第二個(gè)事務(wù)中執(zhí)行 select status from t_items where id=1; 則能正常查詢出數(shù)據(jù)，不會(huì)受第一個(gè)事務(wù)的影響。

使用 select…for update 會(huì)把數(shù)據(jù)給鎖住，不過我們需要注意一些鎖的級(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ǔ)句明確指定主鍵，但是卻查無此數(shù)據(jù)，此時(shí)不會(huì)產(chǎn)生lock（沒有元數(shù)據(jù)，又去lock誰(shuí)呢？）。

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

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

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ù)索引查無此數(shù)據(jù)，也就不會(huì)產(chǎn)生lock。

樂觀鎖（ Optimistic Locking ） 相對(duì)悲觀鎖而言，樂觀鎖假設(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)樂觀鎖一般來說有以下2種方式：

mysql事務(wù)的四大特性是什么？

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

2、 一致性（Consistency）一致性是指事務(wù)必須使數(shù)據(jù)庫(kù)從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)，也就是說一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。

拿轉(zhuǎn)賬來說，假設(shè)用戶A和用戶B兩者的錢加起來一共是5000，那么不管A和B之間如何轉(zhuǎn)賬，轉(zhuǎn)幾次賬，事務(wù)結(jié)束后兩個(gè)用戶的錢相加起來應(yīng)該還得是5000，這就是事務(wù)的一致性。

3、隔離性（Isolation）隔離性是當(dāng)多個(gè)用戶并發(fā)訪問數(shù)據(jù)庫(kù)時(shí)，比如操作同一張表時(shí)，數(shù)據(jù)庫(kù)為每一個(gè)用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。

即要達(dá)到這么一種效果：對(duì)于任意兩個(gè)并發(fā)的事務(wù)T1和T2，在事務(wù)T1看來，T2要么在T1開始之前就已經(jīng)結(jié)束，要么在T1結(jié)束之后才開始，這樣每個(gè)事務(wù)都感覺不到有其他事務(wù)在并發(fā)地執(zhí)行。

4、持久性（Durability）持久性是指一個(gè)事務(wù)一旦被提交了，那么對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫(kù)系統(tǒng)遇到故障的情況下也不會(huì)丟失提交事務(wù)的操作。

擴(kuò)展資料

MyISAMMySQL5.0之前的默認(rèn)數(shù)據(jù)庫(kù)引擎，最為常用。擁有較高的插入，查詢速度，但不支持事務(wù)InnoDB事務(wù)型數(shù)據(jù)庫(kù)的首選引擎，支持ACID事務(wù)，支持行級(jí)鎖定，MySQL5.5起成為默認(rèn)數(shù)據(jù)庫(kù)引擎BDB源自BerkeleyDB，事務(wù)型數(shù)據(jù)庫(kù)的另一種選擇，支持Commit和Rollback等其他事務(wù)特性Memory所有數(shù)據(jù)置于內(nèi)存的存儲(chǔ)引擎，擁有極高的插入，更新和查詢效率。

但是會(huì)占用和數(shù)據(jù)量成正比的內(nèi)存空間。并且其內(nèi)容會(huì)在MySQL重新啟動(dòng)時(shí)丟失Merge將一定數(shù)量的MyISAM表聯(lián)合而成一個(gè)整體，在超大規(guī)模數(shù)據(jù)存儲(chǔ)時(shí)很有用Archive非常適合存儲(chǔ)大量的獨(dú)立的，作為歷史記錄的數(shù)據(jù)。

因?yàn)樗鼈儾唤?jīng)常被讀取。Archive擁有高效的插入速度，但其對(duì)查詢的支持相對(duì)較差Federated將不同的MySQL服務(wù)器聯(lián)合起來，邏輯上組成一個(gè)完整的數(shù)據(jù)庫(kù)。非常適合分布式應(yīng)用Cluster/NDB高冗余的存儲(chǔ)引擎，用多臺(tái)數(shù)據(jù)機(jī)器聯(lián)合提供服務(wù)以提高整體性能和安全性。適合數(shù)據(jù)量大，安全和性能要求高的應(yīng)用