分別是原子性、一致性、隔離性、持久性。
創(chuàng)新互聯(lián)自2013年創(chuàng)立以來，先為江陰等服務建站，江陰等地企業(yè)，進行企業(yè)商務咨詢服務。為江陰企業(yè)網(wǎng)站制作PC+手機+微官網(wǎng)三網(wǎng)同步一站式服務解決您的所有建站問題。
原子性是指事務包含的所有操作要么全部成功，要么全部失敗回滾，因此事務的操作如果成功就必須要完全應用到數(shù)據(jù)庫，如果操作失敗則不能對數(shù)據(jù)庫有任何影響。
一致性是指事務必須使數(shù)據(jù)庫從一個一致性狀態(tài)變換到另一個一致性狀態(tài)，也就是說一個事務執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。舉例來說，假設用戶A和用戶B兩者的錢加起來一共是1000，那么不管A和B之間如何轉賬、轉幾次賬，事務結束后兩個用戶的錢相加起來應該還得是1000，這就是事務的一致性。
隔離性是當多個用戶并發(fā)訪問數(shù)據(jù)庫時，比如同時操作同一張表時，數(shù)據(jù)庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個并發(fā)事務之間要相互隔離。關于事務的隔離性數(shù)據(jù)庫提供了多種隔離級別，稍后會介紹到。
持久性是指一個事務一旦被提交了，那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會丟失提交事務的操作。例如我們在使用JDBC操作數(shù)據(jù)庫時，在提交事務方法后，提示用戶事務操作完成，當我們程序執(zhí)行完成直到看到提示后，就可以認定事務已經(jīng)正確提交，即使這時候數(shù)據(jù)庫出現(xiàn)了問題，也必須要將我們的事務完全執(zhí)行完成。否則的話就會造成我們雖然看到提示事務處理完畢，但是數(shù)據(jù)庫因為故障而沒有執(zhí)行事務的重大錯誤。這是不允許的。
在數(shù)據(jù)庫操作中，在并發(fā)的情況下可能出現(xiàn)如下問題：
正是為了解決以上情況，數(shù)據(jù)庫提供了幾種隔離級別。
數(shù)據(jù)庫事務的隔離級別有4個，由低到高依次為Read uncommitted(未授權讀取、讀未提交)、Read committed（授權讀取、讀提交）、Repeatable read（可重復讀?。erializable（序列化），這四個級別可以逐個解決臟讀、不可重復讀、幻象讀這幾類問題。
雖然數(shù)據(jù)庫的隔離級別可以解決大多數(shù)問題，但是靈活度較差，為此又提出了悲觀鎖和樂觀鎖的概念。
悲觀鎖，它指的是對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理）修改持保守態(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。假設商品的id為1。
如果不采用鎖，那么操作方法如下：
但是上面這種場景在高并發(fā)訪問的情況下很可能會出現(xiàn)問題。例如當?shù)谝徊讲僮髦?，查詢出來的商品status為1。但是當我們執(zhí)行第三步Update操作的時候，有可能出現(xiàn)其他人先一步對商品下單把t_items中的status修改為2了，但是我們并不知道數(shù)據(jù)已經(jīng)被修改了，這樣就可能造成同一個商品被下單2次，使得數(shù)據(jù)不一致。所以說這種方式是不安全的。
在上面的場景中，商品信息從查詢出來到修改，中間有一個處理訂單的過程，使用悲觀鎖的原理就是，當我們在查詢出t_items信息后就把當前的數(shù)據(jù)鎖定，直到我們修改完畢后再解鎖。那么在這個過程中，因為t_items被鎖定了，就不會出現(xiàn)有第三者來對其進行修改了。需要注意的是，要使用悲觀鎖，我們必須關閉mysql數(shù)據(jù)庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執(zhí)行一個更新操作后，MySQL會立刻將結果進行提交。我們可以使用命令設置MySQL為非autocommit模式： set autocommit=0;
設置完autocommit后，我們就可以執(zhí)行我們的正常業(yè)務了。具體如下：
上面的begin/commit為事務的開始和結束，因為在前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交。
上面的第一步我們執(zhí)行了一次查詢操作： select status from t_items where id=1 for update; 與普通查詢不一樣的是，我們使用了 select…for update 的方式，這樣就通過數(shù)據(jù)庫實現(xiàn)了悲觀鎖。此時在t_items表中，id為1的那條數(shù)據(jù)就被我們鎖定了，其它的事務必須等本次事務提交之后才能執(zhí)行。這樣我們可以保證當前的數(shù)據(jù)不會被其它事務修改。需要注意的是，在事務中，只有 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個數(shù)據(jù)時才會等待其它事務結束后才執(zhí)行，一般 SELECT ... 則不受此影響。拿上面的實例來說，當我執(zhí)行 select status from t_items where id=1 for update; 后。我在另外的事務中如果再次執(zhí)行 select status from t_items where id=1 for update; 則第二個事務會一直等待第一個事務的提交，此時第二個查詢處于阻塞的狀態(tài)，但是如果我是在第二個事務中執(zhí)行 select status from t_items where id=1; 則能正常查詢出數(shù)據(jù)，不會受第一個事務的影響。
使用 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，即在當前事務提交前整張數(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; （假設為status字段添加了索引）
這條語句明確指定了索引，并且有此數(shù)據(jù)，則產(chǎn)生row lock。
6、 select * from t_items where status=3 for update; （假設為status字段添加了索引）
這條語句明確指定索引，但是根據(jù)索引查無此數(shù)據(jù)，也就不會產(chǎn)生lock。
樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數(shù)據(jù)一般情況下不會造成沖突，所以只會在數(shù)據(jù)進行提交更新的時候，才會正式對數(shù)據(jù)的沖突與否進行檢測，如果發(fā)現(xiàn)沖突了，則返回用戶錯誤的信息，讓用戶決定如何去做。實現(xiàn)樂觀鎖一般來說有以下2種方式：
以上不是重點，重點是 對事務控制語句不熟悉。
SAVEPOINT identifier : 在事務中 創(chuàng)建保存點。一個事務中 允許有多個保存點。
RELEASE SAVEPOINT identifier : 刪除保存點。當事務中 沒有指定的 保存點，執(zhí)行該語句 會拋異常。
ROLLBACK TO identifier : 把事務回滾到 保存點。
Say you have a table T with a column C with one row in it, say it has the value '1'. And consider you have a simple task like following:
That is a simple task that issue two reads from table T, with a delay of 1 minute between them.
If you follow the logic above you can quickly realize that SERIALIZABLE transactions, while they may make life easy for you, are always completely blocking every possible concurrent operation, since they require that nobody can modify, delete nor insert any row. The default transaction isolation level of the .Net System.Transactions scope is serializable, and this usually explains the abysmal performance that results.
在Repeatable Read隔離級別下，一個事務可能會遇到幻讀（Phantom Read）的問題。
幻讀是指，在一個事務中，第一次查詢某條記錄，發(fā)現(xiàn)沒有，但是，當試圖更新這條不存在的記錄時，竟然能成功，并且，再次讀取同一條記錄，它就神奇地出現(xiàn)了。
我們?nèi)匀幌葴蕚浜胹tudents表的數(shù)據(jù)：
然后，分別開啟兩個MySQL客戶端連接，按順序依次執(zhí)行事務A和事務B：
事務B在第3步第一次讀取id=99的記錄時，讀到的記錄為空，說明不存在id=99的記錄。隨后，事務A在第4步插入了一條id=99的記錄并提交。事務B在第6步再次讀取id=99的記錄時，讀到的記錄仍然為空，但是，事務B在第7步試圖更新這條不存在的記錄時，竟然成功了，并且，事務B在第8步再次讀取id=99的記錄時，記錄出現(xiàn)了。
可見，幻讀就是沒有讀到的記錄，以為不存在，但其實是可以更新成功的，并且，更新成功后，再次讀取，就出現(xiàn)了。
在沖突較少的情況下，使用樂觀鎖。樂觀鎖 因為沒有 加鎖 釋放鎖，也減少了 加鎖 釋放鎖的開銷。
沖突較多時，如果使用樂觀鎖 需要不停地嘗試，所以 使用悲觀鎖。
如果樂觀鎖 進行嘗試時 的花銷較大，也是使用悲觀鎖。
關于mysql中的樂觀鎖和悲觀鎖面試的時候被問到的概率還是比較大的。
mysql的悲觀鎖：
其實理解起來非常簡單，當數(shù)據(jù)被外界修改持保守態(tài)度，包括自身系統(tǒng)當前的其他事務，以及來自外部系統(tǒng)的事務處理，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處于鎖定狀態(tài)。悲觀鎖的實現(xiàn)，往往依靠數(shù)據(jù)庫提供的鎖機制，但是也只有數(shù)據(jù)庫層提供的鎖機制才能真正保證數(shù)據(jù)訪問的排他性，否則，即使在自身系統(tǒng)中實現(xiàn)了加鎖機制，也無法保證外部系統(tǒng)不會修改數(shù)據(jù)。
來點實際的，當我們使用悲觀鎖的時候我們首先必須關閉mysql數(shù)據(jù)庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執(zhí)行一個更新操作后，MySQL會立刻將結果進行提交。
關閉命令為：set autocommit=0;
悲觀鎖可以使用select…for update實現(xiàn)，在執(zhí)行的時候會鎖定數(shù)據(jù)，雖然會鎖定數(shù)據(jù)，但是不影響其他事務的普通查詢使用。此處說普通查詢就是平時我們用的：select * from table 語句。在我們使用悲觀鎖的時候事務中的語句例如：
//開始事務
begin;/begin work;/start transaction; (三選一)
//查詢信息
select * from order where id=1 for update;
//修改信息
update order set name='names';
//提交事務
commit;/commit work;(二選一)
此處的查詢語句for update關鍵字，在事務中只有SELECT ... FOR UPDATE 或LOCK IN SHARE MODE 同一條數(shù)據(jù)時會等待其它事務結束后才執(zhí)行，一般的SELECT查詢則不受影響。
執(zhí)行事務時關鍵字select…for update會鎖定數(shù)據(jù)，防止其他事務更改數(shù)據(jù)。但是鎖定數(shù)據(jù)也是有規(guī)則的。
查詢條件與鎖定范圍：
1、具體的主鍵值為查詢條件
比如查詢條件為主鍵ID=1等等，如果此條數(shù)據(jù)存在，則鎖定當前行數(shù)據(jù)，如果不存在，則不鎖定。
2、不具體的主鍵值為查詢條件
比如查詢條件為主鍵ID1等等，此時會鎖定整張數(shù)據(jù)表。
3、查詢條件中無主鍵
會鎖定整張數(shù)據(jù)表。
4、如果查詢條件中使用了索引為查詢條件
明確指定索引并且查到，則鎖定整條數(shù)據(jù)。如果找不到指定索引數(shù)據(jù)，則不加鎖。
悲觀鎖的確保了數(shù)據(jù)的安全性，在數(shù)據(jù)被操作的時候鎖定數(shù)據(jù)不被訪問，但是這樣會帶來很大的性能問題。因此悲觀鎖在實際開發(fā)中使用是相對比較少的。
mysql的樂觀鎖：
相對悲觀鎖而言，樂觀鎖假設數(shù)據(jù)一般情況下不會造成沖突，所以在數(shù)據(jù)進行提交更新的時候，才會對數(shù)據(jù)的沖突與否進行檢測，如果發(fā)現(xiàn)沖突，則讓返回用戶錯誤的信息，讓用戶決定如何去做。
一般來說，實現(xiàn)樂觀鎖的方法是在數(shù)據(jù)表中增加一個version字段，每當數(shù)據(jù)更新的時候這個字段執(zhí)行加1操作。這樣當數(shù)據(jù)更改的時候，另外一個事務訪問此條數(shù)據(jù)進行更改的話就會操作失敗，從而避免了并發(fā)操作錯誤。當然，還可以將version字段改為時間戳，不過原理都是一樣的。
例如有表student，字段：
id,name,version
1 a 1
當事務一進行更新操作：update student set name='ygz' where id = #{id} and version = #{version};
此時操作完后數(shù)據(jù)會變?yōu)閕d = 1,name = ygz,version = 2，當另外一個事務二同樣執(zhí)行更新操作的時候，卻發(fā)現(xiàn)version != 1，此時事務二就會操作失敗，從而保證了數(shù)據(jù)的正確性。
悲觀鎖和樂觀鎖都是要根據(jù)具體業(yè)務來選擇使用，本文僅作簡單介紹。
首先僅僅加上selelct for update是不足夠的，還必須利用事務保證操作的原子性。
保證不會出現(xiàn)多線程并發(fā)問題：
僅僅使用事務保證原子性：
其他線程還是可以獲取記錄進行覆蓋。
僅僅使用了行鎖：
MySQL的每一個操作都是開啟事務的，并且會自動提交，僅僅加入行鎖，第一步操作后就事務提交釋放，依舊會被覆蓋記錄。
重慶分公司
重慶分公司
