分別是原子性、一致性、隔離性、永續性。
原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。
一致性是指事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態,也就是說乙個事務執行之前和執行之後都必須處於一致性狀態。舉例來說,假設使用者a和使用者b兩者的錢加起來一共是1000,那麼不管a和b之間如何轉賬、轉幾次賬,事務結束後兩個使用者的錢相加起來應該還得是1000,這就是事務的一致性。
隔離性是當多個使用者併發訪問資料庫時,比如同時操作同一張表時,資料庫為每乙個使用者開啟的事務,不能被其他事務的操作所干擾,多個併發事務之間要相互隔離。關於事務的隔離性資料庫提供了多種隔離級別,稍後會介紹到。
永續性是指乙個事務一旦被提交了,那麼對資料庫中的資料的改變就是永久性的,即便是在資料庫系統遇到故障的情況下也不會丟失提交事務的操作。例如我們在使用jdbc運算元據庫時,在提交事務方法後,提示使用者事務操作完成,當我們程式執行完成直到看到提示後,就可以認定事務已經正確提交,即使這時候資料庫出現了問題,也必須要將我們的事務完全執行完成。否則的話就會造成我們雖然看到提示事務處理完畢,但是資料庫因為故障而沒有執行事務的重大錯誤。這是不允許的。
在資料庫操作中,在併發的情況下可能出現如下問題:
正是為了解決以上情況,資料庫提供了幾種隔離級別。
資料庫事務的隔離級別有4個,由低到高依次為read uncommitted(未授權讀取、讀未提交)、read committed(授權讀取、讀提交)、repeatable read(可重複讀取)、serializable(序列化),這四個級別可以逐個解決髒讀、不可重複讀、幻象讀這幾類問題。
雖然資料庫的隔離級別可以解決大多數問題,但是靈活度較差,為此又提出了悲觀鎖和樂觀鎖的概念。
悲觀鎖,它指的是對資料被外界(包括本系統當前的其他事務,以及來自外部系統的事務處理)修改持保守態度。因此,在整個資料處理過程中,將資料處於鎖定狀態。悲觀鎖的實現,往往依靠資料庫提供的鎖機制。也只有資料庫層提供的鎖機制才能真正保證資料訪問的排他性,否則,即使在本系統的資料訪問層中實現了加鎖機制,也無法保證外部系統不會修改資料。
商品t_items表中有乙個欄位status,status為1代表商品未被下單,status為2代表商品已經被下單(此時該商品無法再次下單),那麼我們對某個商品下單時必須確保該商品status為1。假設商品的id為1。
如果不採用鎖,那麼操作方法如下:
//1.查詢出商品資訊
select status from t_items where id=1;
//2.根據商品資訊生成訂單,並插入訂單表 t_orders
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status為2
update t_items set status=2;
但是上面這種場景在高併發訪問的情況下很可能會出現問題。例如當第一步操作中,查詢出來的商品status為1。但是當我們執行第三步update操作的時候,有可能出現其他人先一步對商品下單把t_items中的status修改為2了,但是我們並不知道資料已經被修改了,這樣就可能造成同乙個商品被下單2次,使得資料不一致。所以說這種方式是不安全的。
在上面的場景中,商品資訊從查詢出來到修改,中間有乙個處理訂單的過程,使用悲觀鎖的原理就是,當我們在查詢出t_items資訊後就把當前的資料鎖定,直到我們修改完畢後再解鎖。那麼在這個過程中,因為t_items被鎖定了,就不會出現有第三者來對其進行修改了。需要注意的是,要使用悲觀鎖,我們必須關閉mysql資料庫的自動提交屬性,因為mysql預設使用autocommit模式,也就是說,當你執行乙個更新操作後,mysql會立刻將結果進行提交。我們可以使用命令設定mysql為非autocommit模式:set autocommit=0;
設定完autocommit後,我們就可以執行我們的正常業務了。具體如下:
//0.開始事務
begin;/begin work;/start transaction; (三者選一就可以)
//1.查詢出商品資訊
select status from t_items where id=1 for update;
//2.根據商品資訊生成訂單
insert into t_orders (id,goods_id) values (null,1);
//3.修改商品status為2
update t_items set status=2;
//4.提交事務
commit;/commit work;
上面的begin/commit為事務的開始和結束,因為在前一步我們關閉了mysql的autocommit,所以需要手動控制事務的提交。
上面的第一步我們執行了一次查詢操作:select status from t_items where id=1 for update;
與普通查詢不一樣的是,我們使用了select…for update
的方式,這樣就通過資料庫實現了悲觀鎖。此時在t_items表中,id為1的那條資料就被我們鎖定了,其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的資料不會被其它事務修改。需要注意的是,在事務中,只有select ... for update
或lock in share mode
操作同乙個資料時才會等待其它事務結束後才執行,一般select ...
則不受此影響。拿上面的例項來說,當我執行select status from t_items where id=1 for update;
後。我在另外的事務中如果再次執行select status from t_items where id=1 for update;
則第二個事務會一直等待第乙個事務的提交,此時第二個查詢處於阻塞的狀態,但是如果我是在第二個事務中執行select status from t_items where id=1;
則能正常查詢出資料,不會受第乙個事務的影響。
使用select…for update
會把資料給鎖住,不過我們需要注意一些鎖的級別,mysql innodb預設row-level lock,所以只有「明確」地指定主鍵或者索引,mysql 才會執行row lock (只鎖住被選取的資料) ,否則mysql 將會執行table lock (將整個資料表單給鎖住)。舉例如下:
1、select * from t_items where id=1 for update;
這條語句明確指定主鍵(id=1),並且有此資料(id=1的資料存在),則採用row lock。只鎖定當前這條資料。
2、select * from t_items where id=3 for update;
這條語句明確指定主鍵,但是卻查無此資料,此時不會產生lock(沒有元資料,又去lock誰呢?)。
3、select * from t_items where name='手機' for update;
這條語句沒有指定資料的主鍵,那麼此時產生table lock,即在當前事務提交前整張資料表的所有欄位將無法被查詢。
4、select * from t_items where id>0 for update;
或者select * from t_items where id<>1 for update;
(注:<>在sql中表示不等於)
上述兩條語句的主鍵都不明確,也會產生table lock。
5、select * from t_items where status=1 for update;
(假設為status欄位新增了索引)
這條語句明確指定了索引,並且有此資料,則產生row lock。
6、select * from t_items where status=3 for update;
(假設為status欄位新增了索引)
這條語句明確指定索引,但是根據索引查無此資料,也就不會產生lock。
樂觀鎖( optimistic locking ) 相對悲觀鎖而言,樂觀鎖假設認為資料一般情況下不會造成衝突,所以只會在資料進行提交更新的時候,才會正式對資料的衝突與否進行檢測,如果發現衝突了,則返回使用者錯誤的資訊,讓使用者決定如何去做。實現樂觀鎖一般來說有以下2種方式:
mysql的事務四個特性以及事務的四個隔離級別
分別是原子性 一致性 隔離性 永續性。原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。一致性是指事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態,也就是說乙個事務執行之前和執行之後都必須處於一致性...
mysql的事務四個特性以及事務的四個隔離級別
分別是原子性 一致性 隔離性 永續性。原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。一致性是指事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態,也就是說乙個事務執行之前和執行之後都必須處於一致性...
mysql的事務四個特性以及事務的四個隔離級別
分別是原子性 一致性 隔離性 永續性。原子性是指事務包含的所有操作要麼全部成功,要麼全部失敗回滾,因此事務的操作如果成功就必須要完全應用到資料庫,如果操作失敗則不能對資料庫有任何影響。一致性是指事務必須使資料庫從乙個一致性狀態變換到另乙個一致性狀態,也就是說乙個事務執行之前和執行之後都必須處於一致性...