事務(wù)是數(shù)據(jù)庫操作最小單元，把多件事當(dāng)一件事來處理，是一組不可在分割的操作集合。作為單個邏輯工作單元執(zhí)行一系列操作，這些操作作為一個整體一起向系統(tǒng)提交，要么都執(zhí)行，要么都不執(zhí)行。
撫遠(yuǎn)網(wǎng)站建設(shè)公司創(chuàng)新互聯(lián),撫遠(yuǎn)網(wǎng)站設(shè)計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為撫遠(yuǎn)上千余家提供企業(yè)網(wǎng)站建設(shè)服務(wù)。企業(yè)網(wǎng)站搭建\外貿(mào)營銷網(wǎng)站建設(shè)要多少錢，請找那個售后服務(wù)好的撫遠(yuǎn)做網(wǎng)站的公司定做！
特性ACID（原子性、一致性、隔離性、持久性）
原子性：原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，，因此事務(wù)操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫，如果操作失敗則不能對數(shù)據(jù)庫有一點影響。
一致性：一致性是指事務(wù)必須使數(shù)據(jù)庫從一個一致性狀態(tài)轉(zhuǎn)換到另一個一致性狀態(tài)，就是說事務(wù)執(zhí)行前后都必須處在一致性狀態(tài)。
隔離性：隔離性使當(dāng)多個用戶訪問數(shù)據(jù)庫時，比如操作同一張表，數(shù)據(jù)庫開啟的每一個事務(wù)，不能被其它事務(wù)干擾，多個并發(fā)事務(wù)之間相互隔離。
持久性：持久性是指一個事務(wù)一旦提交，對數(shù)據(jù)庫中數(shù)據(jù)的改變是永久的，即使是數(shù)據(jù)庫系統(tǒng)遇到故障也不會丟失提交的事務(wù)操作。
MySQL 事務(wù)
什么是事務(wù)？
MySQL 事務(wù)主要用于處理操作量大，復(fù)雜度高的數(shù)據(jù)。比如說，在人員管理系統(tǒng)中，你刪除一個人員，你既需要刪除人員的基本資料，也要刪除和該人員相關(guān)的信息，如信箱，文章等等，這樣，這些數(shù)據(jù)庫操作語句就構(gòu)成一個事務(wù)！
在 MySQL 中只有使用了 Innodb 數(shù)據(jù)庫引擎的數(shù)據(jù)庫或表才支持事務(wù)。
事務(wù)處理可以用來維護(hù)數(shù)據(jù)庫的完整性，保證成批的 SQL 語句要么全部執(zhí)行，要么全部不執(zhí)行。
事務(wù)用來管理 insert,update,delete 語句
一般來說，事務(wù)是必須滿足4個條件（ACID）：原子性（Atomicity，或稱不可分割性）、一致性（Consistency）、隔離性（Isolation，又稱獨立性）、持久性（Durability）。
原子性：一個事務(wù)（transaction）中的所有操作，要么全部完成，要么全部不完成，不會結(jié)束在中間某個環(huán)節(jié)。事務(wù)在執(zhí)行過程中發(fā)生錯誤，會被回滾（Rollback）到事務(wù)開始前的狀態(tài)，就像這個事務(wù)從來沒有執(zhí)行過一樣。
一致性：在事務(wù)開始之前和事務(wù)結(jié)束以后，數(shù)據(jù)庫的完整性沒有被破壞。這表示寫入的資料必須完全符合所有的預(yù)設(shè)規(guī)則，這包含資料的精確度、串聯(lián)性以及后續(xù)數(shù)據(jù)庫可以自發(fā)性地完成預(yù)定的工作。
隔離性：數(shù)據(jù)庫允許多個并發(fā)事務(wù)同時對其數(shù)據(jù)進(jìn)行讀寫和修改的能力，隔離性可以防止多個事務(wù)并發(fā)執(zhí)行時由于交叉執(zhí)行而導(dǎo)致數(shù)據(jù)的不一致。事務(wù)隔離分為不同級別，包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）。
持久性：事務(wù)處理結(jié)束后，對數(shù)據(jù)的修改就是永久的，即便系統(tǒng)故障也不會丟失。
在 MySQL 命令行的默認(rèn)設(shè)置下，事務(wù)都是自動提交的，即執(zhí)行 SQL 語句后就會馬上執(zhí)行 COMMIT 操作。因此要顯式地開啟一個事務(wù)務(wù)須使用命令 BEGIN 或 START TRANSACTION，或者執(zhí)行命令 SET AUTOCOMMIT=0，用來禁止使用當(dāng)前會話的自動提交。
from 樹懶學(xué)堂 - 一站式數(shù)據(jù)知識平臺
當(dāng)多個用戶訪問同一份數(shù)據(jù)時，一個用戶在更改數(shù)據(jù)的過程中，可能有其他用戶同時發(fā)起更改請求，為保證數(shù)據(jù)庫記錄的更新從一個一致性狀態(tài)變?yōu)榱硗庖粋€一致性狀態(tài)，使用事務(wù)處理是非常必要的，事務(wù)具有以下四個特性：
MySQL 提供了多種事務(wù)型存儲引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事務(wù)。為了支持事務(wù)，InnoDB 存儲引擎引入了與事務(wù)處理相關(guān)的 REDO 日志和 UNDO 日志，同時事務(wù)依賴于 MySQL 提供的鎖機(jī)制
事務(wù)執(zhí)行時需要將執(zhí)行的事務(wù)日志寫入日志文件，對應(yīng)的文件為 REDO 日志。當(dāng)每條 SQL 進(jìn)行數(shù)據(jù)更新操作時，首先將 REDO 日志寫進(jìn)日志緩沖區(qū)。當(dāng)客戶端執(zhí)行 COMMIT 命令提交時，日志緩沖區(qū)的內(nèi)容將被刷新到磁盤，日志緩沖區(qū)的刷新方式或者時間間隔可以通過參數(shù) innodb_flush_log_at_trx_commit 控制
REDO 日志對應(yīng)磁盤上的 ib_logifleN 文件，該文件默認(rèn)為 5MB，建議設(shè)置為 512MB，以便容納較大的事務(wù)。MySQL 崩潰恢復(fù)時會重新執(zhí)行 REDO 日志的記錄，恢復(fù)最新數(shù)據(jù)，保證已提交事務(wù)的持久性
與 REDO 日志相反，UNDO 日志主要用于事務(wù)異常時的數(shù)據(jù)回滾，具體內(nèi)容就是記錄數(shù)據(jù)被修改前的信息到 UNDO 緩沖區(qū)，然后在合適的時間將內(nèi)容刷新到磁盤
假如由于系統(tǒng)錯誤或者 rollback 操作而導(dǎo)致事務(wù)回滾，可以根據(jù) undo 日志回滾到?jīng)]修改前的狀態(tài)，保證未提交事務(wù)的原子性
與 REDO 日志不同的是，磁盤上不存在單獨的 UNDO 日志文件，所有的 UNDO 日志均存在表空間對應(yīng)的 .ibd 數(shù)據(jù)文件中，即使 MySQL 服務(wù)啟動了獨立表空間
在 MySQL 中，可以使用 BEGIN 開始事務(wù)，使用 COMMIT 結(jié)束事務(wù)，中間可以使用 ROLLBACK 回滾事務(wù)。MySQL 通過 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等語句支持本地事務(wù)
MySQL 定義了四種隔離級別，指定事務(wù)中哪些數(shù)據(jù)改變其他事務(wù)可見、哪些數(shù)據(jù)該表其他事務(wù)不可見。低級別的隔離級別可以支持更高的并發(fā)處理，同時占用的系統(tǒng)資源更少
InnoDB 系統(tǒng)級事務(wù)隔離級別可以使用以下語句設(shè)置：
查看系統(tǒng)級事務(wù)隔離級別：
InnoDB 會話級事務(wù)隔離級別可以使用以下語句設(shè)置：
查看會話級事務(wù)隔離級別：
在該隔離級別，所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。讀取未提交的數(shù)據(jù)稱為臟讀（Dirty Read），即是：首先開啟 A 和 B 兩個事務(wù)，在 B 事務(wù)更新但未提交之前，A 事務(wù)讀取到了更新后的數(shù)據(jù)，但由于 B 事務(wù)回滾，導(dǎo)致 A 事務(wù)出現(xiàn)了臟讀現(xiàn)象
所有事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變，此級別可以解決臟讀，但也會導(dǎo)致不可重復(fù)讀（Nonrepeatable Read）：首先開啟 A 和 B 兩個事務(wù)，A事務(wù)讀取了 B 事務(wù)的數(shù)據(jù)，在 B 事務(wù)更新并提交后，A 事務(wù)又讀取到了更新后的數(shù)據(jù)，此時就出現(xiàn)了同一 A 事務(wù)中的查詢出現(xiàn)了不同的查詢結(jié)果
MySQL 默認(rèn)的事務(wù)隔離級別，能確保同一事務(wù)的多個實例在并發(fā)讀取數(shù)據(jù)時看到同樣的數(shù)據(jù)行，理論上會導(dǎo)致一個問題，幻讀（Phontom Read）。例如，第一個事務(wù)對一個表中的數(shù)據(jù)做了修改，這種修改會涉及表中的全部數(shù)據(jù)行，同時第二個事務(wù)也修改這個表中的數(shù)據(jù)，這次的修改是向表中插入一行新數(shù)據(jù)，此時就會發(fā)生操作第一個事務(wù)的用戶發(fā)現(xiàn)表中還有沒有修改的數(shù)據(jù)行
InnoDB 通過多版本并發(fā)控制機(jī)制（MVCC）解決了該問題：InnoDB 通過為每個數(shù)據(jù)行增加兩個隱含值的方式來實現(xiàn)，這兩個隱含值記錄了行的創(chuàng)建時間、過期時間以及每一行存儲時間發(fā)生時的系統(tǒng)版本號，每個查詢根據(jù)事務(wù)的版本號來查詢結(jié)果
通過強(qiáng)制事務(wù)排序，使其不可能相互沖突，從而解決幻讀問題。簡而言之，就是在每個讀的數(shù)據(jù)行上加上共享鎖實現(xiàn)，這個級別會導(dǎo)致大量的超時現(xiàn)象和鎖競爭，一般不推薦使用
為了解決數(shù)據(jù)庫并發(fā)控制問題，如走到同一時刻客戶端對同一張表做更新或者查詢操作，需要對并發(fā)操作進(jìn)行控制，因此產(chǎn)生了鎖
共享鎖的粒度是行或者元組（多個行），一個事務(wù)獲取了共享鎖以后，可以對鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行讀操作
排他鎖的粒度與共享鎖相同，一個事務(wù)獲取排他鎖以后，可以對鎖定范圍內(nèi)的數(shù)據(jù)執(zhí)行寫操作
有兩個事務(wù) A 和 B，如果事務(wù) A 獲取了一個元組的共享鎖，事務(wù) B 還可以立即獲取這個元組的共享鎖，但不能獲取這個元組的排他鎖，必須等到事務(wù) A 釋放共享鎖之后。如果事務(wù) A 獲取了一個元組的排他鎖，事務(wù) B 不能立即獲取這個元組的共享鎖，也不能立即獲取這個元組的排他鎖，必須等到 A 釋放排他鎖之后
意向鎖是一種表鎖，鎖定的粒度是整張表，分為意向共享鎖和意向排他鎖。意向共享鎖表示一個事務(wù)有意對數(shù)據(jù)上共享鎖或者排他鎖。有意表示事務(wù)想執(zhí)行操作但還沒真正執(zhí)行
鎖的粒度主要分為表鎖和行鎖
表鎖的開銷最小，同時允許的并發(fā)量也是最小。MyISAM 存儲引擎使用該鎖機(jī)制。當(dāng)要寫入數(shù)據(jù)時，整個表記錄被鎖，此時其他讀/寫動作一律等待。一些特定的動作，如 ALTER TABLE 執(zhí)行時使用的也是表鎖
行鎖可以支持最大的并發(fā)，InnoDB 存儲引擎使用該鎖機(jī)制。如果要支持并發(fā)讀/寫，建議采用 InnoDB 存儲引擎
分別是原子性、一致性、隔離性、持久性。
原子性是指事務(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ù)的一致性。
隔離性是當(dāng)多個用戶并發(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ù)操作完成，當(dāng)我們程序執(zhí)行完成直到看到提示后，就可以認(rèn)定事務(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)當(dāng)前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度。因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機(jī)制。也只有數(shù)據(jù)庫層提供的鎖機(jī)制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在本系統(tǒng)的數(shù)據(jù)訪問層中實現(xiàn)了加鎖機(jī)制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)。
商品t_items表中有一個字段status，status為1代表商品未被下單，status為2代表商品已經(jīng)被下單（此時該商品無法再次下單），那么我們對某個商品下單時必須確保該商品status為1。假設(shè)商品的id為1。
如果不采用鎖，那么操作方法如下：
但是上面這種場景在高并發(fā)訪問的情況下很可能會出現(xiàn)問題。例如當(dāng)?shù)谝徊讲僮髦校樵兂鰜淼纳唐穝tatus為1。但是當(dāng)我們執(zhí)行第三步Update操作的時候，有可能出現(xiàn)其他人先一步對商品下單把t_items中的status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個商品被下單2次，使得數(shù)據(jù)不一致。所以說這種方式是不安全的。
在上面的場景中，商品信息從查詢出來到修改，中間有一個處理訂單的過程，使用悲觀鎖的原理就是，當(dāng)我們在查詢出t_items信息后就把當(dāng)前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個過程中，因為t_items被鎖定了，就不會出現(xiàn)有第三者來對其進(jìn)行修改了。需要注意的是，要使用悲觀鎖，我們必須關(guān)閉mysql數(shù)據(jù)庫的自動提交屬性，因為MySQL默認(rèn)使用autocommit模式，也就是說，當(dāng)你執(zhí)行一個更新操作后，MySQL會立刻將結(jié)果進(jìn)行提交。我們可以使用命令設(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í)行。這樣我們可以保證當(dāng)前的數(shù)據(jù)不會被其它事務(wù)修改。需要注意的是，在事務(wù)中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個數(shù)據(jù)時才會等待其它事務(wù)結(jié)束后才執(zhí)行，一般 SELECT ... 則不受此影響。拿上面的實例來說，當(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; 則第二個事務(wù)會一直等待第一個事務(wù)的提交，此時第二個查詢處于阻塞的狀態(tài)，但是如果我是在第二個事務(wù)中執(zhí)行 select status from t_items where id=1; 則能正常查詢出數(shù)據(jù)，不會受第一個事務(wù)的影響。
使用 select…for update 會把數(shù)據(jù)給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認(rèn)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。只鎖定當(dāng)前這條數(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='手機(jī)' for update;
這條語句沒有指定數(shù)據(jù)的主鍵，那么此時產(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中表示不等于）
上述兩條語句的主鍵都不明確，也會產(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è)認(rèn)為數(shù)據(jù)一般情況下不會造成沖突，所以只會在數(shù)據(jù)進(jìn)行提交更新的時候，才會正式對數(shù)據(jù)的沖突與否進(jìn)行檢測，如果發(fā)現(xiàn)沖突了，則返回用戶錯誤的信息，讓用戶決定如何去做。實現(xiàn)樂觀鎖一般來說有以下2種方式：
1、前言
面試官：我看你簡歷上寫了熟悉redis，看來工作中用的很多吧？
我：是的，我們項目中經(jīng)常用到redis（來，隨便問，看我分分鐘秒殺你）
面試官：那你給我說說redis的事務(wù)和mysql的事務(wù)有什么區(qū)別吧
我：額。。。事務(wù)還有區(qū)別？？？？
面試官：比如說redis的事務(wù)是不支持原子性和持久性的，包括他們的實現(xiàn)原理等方面也是有很大區(qū)別的。
我：學(xué)到了。。。。。。
2、正文
事務(wù)的四大特性
ACID，指數(shù)據(jù)庫事務(wù)正確執(zhí)行的四個基本要素的縮寫。包含：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。
說的是一個事物內(nèi)所有操作就是最小的一個操作單元，要么全部成功，要么全部失敗。這是最基本的特性，保證了因為一些其他因素導(dǎo)致數(shù)據(jù)庫異常，或者宕機(jī)。
一個事務(wù)可以封裝狀態(tài)改變（除非它是一個只讀的）。事務(wù)必須始終保持系統(tǒng)處于一致的狀態(tài)，不管在任何給定的時間并發(fā)事務(wù)有多少。
一致性有下面特點：
在現(xiàn)實中，事務(wù)系統(tǒng)遭遇并發(fā)請求時，這種串行化是有成本的， Amdahl法則描述如下：它是描述序列串行執(zhí)行和并發(fā)之間的關(guān)系。
“一個程序在并行計算情況下使用多個處理器所能提升的速度是由這個程序中串行執(zhí)行部分的時間決定的?！?/p>
大多數(shù)數(shù)據(jù)庫管理系統(tǒng)選擇（默認(rèn)情況下）是放寬一致性，以達(dá)到更好的并發(fā)性。
事物的隔離性，基于原子性和一致性，因為事物是原子化，量子化的，所以，事物可以有多個原子包的形式并發(fā)執(zhí)行，但是，每個事物互不干擾。
但是，由于多個事物可能操作同一個資源，不同的事物為了保證隔離性，會有很多鎖方案，當(dāng)然這是數(shù)據(jù)庫的實現(xiàn)，他們怎么實現(xiàn)的，我們不必深究。
持久性，當(dāng)一個事物提交之后，數(shù)據(jù)庫狀態(tài)永遠(yuǎn)的發(fā)生了改變，即這個事物只要提交了，哪怕提交后宕機(jī)，他也確確實實的提交了，不會出現(xiàn)因為剛剛宕機(jī)了而讓提交不生效，是要事物提交，他就像洗不掉的紋身，永遠(yuǎn)的固化了，除非你毀了硬盤。
事務(wù)命令
mysql：
Begin：顯式的開啟一個事務(wù)
Commit：提交事務(wù)，將對數(shù)據(jù)庫進(jìn)行的所有的修改變成永久性
Rollback：結(jié)束用戶的事務(wù)，并撤銷現(xiàn)在正在進(jìn)行的未提交的修改
redis：
Multi：標(biāo)記事務(wù)的開始
Exec：執(zhí)行事務(wù)的commands隊列
Discard：結(jié)束事務(wù)，并清除commands隊列
默認(rèn)狀態(tài)
mysql：
mysql會默認(rèn)開啟一個事務(wù)，且缺省設(shè)置是自動提交，即每成功執(zhí)行sql，一個事務(wù)就會馬上commit，所以不能rollback，
redis：
redis默認(rèn)不會開啟事務(wù)，即command會立即執(zhí)行，而不會排隊，并不支持rollback
使用方式
mysql（包含兩種方式）：
用Begin、Rollback、commit顯式開啟并控制一個 新的 Transaction
執(zhí)行命令 set autocommit=0，用來禁止當(dāng)前會話自動commit，控制 默認(rèn)開啟的事務(wù)
redis：
用multi、exec、discard，顯式開啟并控制一個Transaction。
（注意：這里沒有強(qiáng)調(diào) “新的” ，因為默認(rèn)是不會開啟事務(wù)的）。
實現(xiàn)原理
mysql：
mysql實現(xiàn)事務(wù)，是基于undo/redo日志
undo記錄修改前狀態(tài)，rollback基于undo日志實現(xiàn)
redo記錄修改后的狀態(tài)，commit基于redo日志實現(xiàn)
既然是基于redo日志實現(xiàn)記錄修改后的狀態(tài)，那么大家應(yīng)該也知道，redo日志是innodb專有的，所以innodb會支持事務(wù)
在mysql中無論是否開啟事務(wù)，sql都會被立即執(zhí)行并返回執(zhí)行結(jié)果，只是事務(wù)開啟后執(zhí)行后的狀態(tài)只是記錄在redo日志，執(zhí)行commit之后，數(shù)據(jù)才會被寫入磁盤
（以上內(nèi)容后面我會詳細(xì)在mysql篇給大家講到，大家可以先簡單了解下）
所以，上述代碼，insertSelective 將會被立即賦值（無論是否開啟事務(wù)，只是結(jié)果或未被寫入磁盤）：
redis:
redis實現(xiàn)事務(wù)，是基于commands隊列
如果沒有開啟事務(wù)，command將會被立即執(zhí)行并返回執(zhí)行結(jié)果，并且直接寫入磁盤
如果事務(wù)開啟，command不會被立即執(zhí)行，而是排入隊列，并返回排隊狀態(tài)（具體依賴于客戶端（例如：spring-data-redis）自身實現(xiàn)）。
調(diào)用exec才會執(zhí)行commands隊列
以上代碼如果沒有開啟事務(wù)，操作被立即執(zhí)行，a將會被立即賦值（true/false）
如果開啟事務(wù)，操作不會被立即執(zhí)行，將會返回null值，而a的類型是boolean，所以將會拋出異常：
Redis事務(wù)不支持Rollback（重點）
事實上Redis命令在事務(wù)執(zhí)行時可能會失敗，但仍會繼續(xù)執(zhí)行剩余命令而不是Rollback（事務(wù)回滾）。如果你使用過關(guān)系數(shù)據(jù)庫，這種情況可能會讓你感到很奇怪。然而針對這種情況具備很好的解釋：
redis 事務(wù)中的錯誤
事務(wù)期間，可能會遇到兩種命令錯誤：
客戶端會在EXEC調(diào)用之前檢測第一種錯誤。 通過檢查排隊命令的狀態(tài)回復(fù)（***注意：這里是指排隊的狀態(tài)回復(fù)，而不是執(zhí)行結(jié)果***），如果命令使用QUEUED進(jìn)行響應(yīng)，則它已正確排隊，否則Redis將返回錯誤。如果排隊命令時發(fā)生錯誤，大多數(shù)客戶端將中止該事務(wù)并清除命令隊列。然而：
這是由于INCR命令的語法錯誤，將在調(diào)用EXEC之前被檢測出來，并終止事務(wù)（version2.6.5+）。
EXEC命令執(zhí)行之后發(fā)生的錯誤并不會被特殊對待：即使事務(wù)中的某些命令執(zhí)行失敗，其他命令仍會被正常執(zhí)行。
什么是事務(wù)？
事務(wù)是邏輯上的一組操作，組成這組操作的各個單元，要不全都成功要不全都失敗，這個特性就是事務(wù)
注意：mysql數(shù)據(jù)支持事務(wù)，但是要求必須是innoDB存儲引擎
解決這個問題：
mysql的事務(wù)解決這個問題，因為mysql的事務(wù)特性，要求這組操作，要不全都成功，要不全都失敗，這樣就避免了某個操作成功某個操作失敗。利于數(shù)據(jù)的安全
如何使用：
（1）在執(zhí)行sql語句之前，我們要開啟事務(wù) start transaction;
（2）正常執(zhí)行我們的sql語句
（3）當(dāng)sql語句執(zhí)行完畢，存在兩種情況：
1，全都成功，我們要將sql語句對數(shù)據(jù)庫造成的影響提交到數(shù)據(jù)庫中，committ
2，某些sql語句失敗，我們執(zhí)行rollback（回滾），將對數(shù)據(jù)庫操作趕緊撤銷
（注意：mysql數(shù)據(jù)支持事務(wù)，但是要求必須是innoDB存儲引擎）
mysql create table bank(name varchar(20),money decimal(5,1))engine=innodb defau
lt charset=utf8;
mysql inset into bank values('shaotuo',1000),('laohu',5000);
mysql select*from bank;
+---------+--------+
| name | money |
+---------+--------+
| shaotuo | 1000.0 |
| laohu | 5000.0 |
+---------+--------+
------沒有成功“回滾”執(zhí)行rollback
mysql start transaction; //開啟事務(wù)
Query OK, 0 rows affected (0.00 sec)
mysql update bank set money=money+500 where name='shaotuo';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql update bank set moey=money-500 where name='laohu';
ERROR 1054 (42S22): Unknown column 'moey' in 'field list'
mysql rollback; //只要有一個不成功，執(zhí)行rollback操作
Query OK, 0 rows affected (0.01 sec)
mysql select*from bank;
+---------+--------+
| name | money |
+---------+--------+
| shaotuo | 1000.0 |
| laohu | 5000.0 |
+---------+--------+
------成功之后 進(jìn)行commit操作
mysql start transaction; //開啟事務(wù)
Query OK, 0 rows affected (0.00 sec)
mysql update bank set money=money+500 where name='shaotuo';
Query OK, 1 row affected (0.01 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql update bank set money=money-500 where name='laohu';
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql commit; //兩個都成功后執(zhí)行commit（只要不執(zhí)行commit，sql語句不會對真實的數(shù)據(jù)庫造成影響）
Query OK, 0 rows affected (0.05 sec)
mysql select*from bank;
+---------+--------+
| name | money |
+---------+--------+
| shaotuo | 1500.0 |
| laohu | 4500.0 |
+---------+--------+
重慶分公司
重慶分公司
