您好,登錄后才能下訂單哦!
?
?
?
transaction:
事務,由若干條語句組成的,指要做的一系列操作;
InnoDB引擎,支持事務;
?
atomicity,一個事務是一個不可分割的工作單位,事務中包括的所有操作要么全部做完,要做什么都不做;
consistency,事務必須是使數據庫從一個一致性狀態變成另一個一致性狀態,一致性和原子性是密切相關的;
isolation,一個事務的執行不能被其它事務干擾,即一個事務內部的操作及使用的數據對并發的其它事務是隔離的,并發執行的各個事務之間不能互相干擾;
durability,持久性也稱永久性permanence,指一個事務一旦提交,它對數據庫中數據的改變就應該是永久性的,接下來的其它操作或故障不應該對其有任何影響;
?
注:
atomicity要求事務中的所有操作,不可分割,不能做了一部分操作,還剩一部分操作;
consistency,多個事務并行執行的結果,應該和事務排隊執行的結果一致,如果事務的并行執行和多線程讀寫共享資源一樣不可預期,就不能保證一致性;
isolation,指多個事務訪問共同的數據了,應該互不干擾,隔離性指究竟在一個事務處理期間,其它事務能不能訪問的問題;
durability,事務提交后,數據不能丟失;
?
?
不允許事務A和事務B并行;
例,事務A和事務B,更新同一個數據,它們都讀取了初始值100,A要減10,B要加100,A減去10后更新為90,B加100更新為200,A的更新丟失了;
?
只用于展示可以,用于計算可以;
事務B讀到了事務A未提交的數據,這個數據可能是一個中間值,也可能事務A之后回滾事務,事務A是否最后提交并不關心,只要讀到了這個被修改的數據就是臟讀,隔離不好,讀到了未提交的數據(中間狀態值);
?
允許后一次可讀到正確的內容;
不能保證同一條查詢語句重復讀相同的結果,就是不可重復讀;
例,事務A在同一事務中執行相同查詢語句(先后查詢了2次),得到了不同的結果(不能重復的獲取相同數據);
例,事務A在查詢了一次后,事務B修改了數據,事務A又查詢一次,發現數據不一致了;沒說提交;
注:臟讀是可以讀到相同數據的,但讀取的是一個未提交的數據,不是提交的最終結果;
?
例,事務A中同一個查詢要進行多次,事務B插入數據,導致事務A返回了不同的結果集,如同幻覺;
數據集有記錄增加了,可以看作是增加了記錄的不可重復讀;
?
有以上問題,數據庫必須要解決,解決辦法:1、隔離級別;2、加鎖;
?
由低到高,依次為:
read uncommitted,讀取到未提交數據,讀不受約束;
read commited,讀已經提交的數據,oralce默認;
repeabable read,可以重復讀,MySQL默認,解決不可重復讀;
serializable,串行化,事務間完全隔離,不能并發只能串行,解決了所有問題;
?
隔離級別越高,串行化越高,數據庫執行效率越低,當前事務處理的中間結果對其它事務不可見程度越高;
隔離級別越低,并行度越高,性能越高;
?
會話級別|全局級別:
>set [session|global] transaction isolation level LEVEL;?? #生產中慎用global
>select @@global.tx_isolation;
>select @@tx_isolation;
>set session transaction isolation level read committed;
?
serializable,串行了,解決所有問題;
?
repeatable read:
事務A中同一條查詢語句返回同樣的結果,就是可以重復讀數據了,解決辦法有:
1、對select的數據加鎖,不允許其它事務有刪除、修改操作,如for update;
2、第一次select時,對最后一次確切提交的事務的結果的快照;
以上解決了不可重復讀,但有可能出現幻讀;
?
read committed:
在事務中,每次select可以讀到別的事務剛提交成功的新的數據,因為讀到的是提交后的數據,解決了臟讀,但不能解決不可重復讀的問題;
?
read uncommitted:
能讀取到別的事務還沒提交的數據,完全沒有隔離性可言,出現了臟讀;
?
事務語法:
>start transaction?? #或>begin開始一個事務,>start transaction是標準sql語法;
>commit?? #提交事務后,變更成為永久變更;
>rollback?? #可在提交事務之前,回滾變更,事務中的操作就如同沒有發生過一樣;
>set autocommit=0?? #默認autocommit模式,可禁用或啟用,用于當前連接,出錯也可自動回滾,0禁用自動提交事務,如果開啟自動提交,若有一個修改表的語句,執行后會立即把更新存儲到磁盤;開發時一般會關掉此項,性能問題,是一批批的提交,而不是一句句的提交;
?
?
本質上來說沒有區別,都是存放數據的地方;
數據庫支持在線業務,需要頻繁增刪改查;數據倉庫一般囤積歷史數據支持用于分析的SQL,一般不建議刪改;
?
數據庫關注數據的持久化、數據的關系,為業務系統提供支持、事務支持;
OLTP,在線交易數據,數據庫;
?
數據倉庫,存儲的數據是為了分析或者發掘而設計的表結構,可以存儲海量數據;
數據倉庫存儲歷史數據用于分析OLAP;
?
?
操作查詢的結果集的一種方法;
可將游標當作一個指針,指向結果集中的某一行;
?
這兩種技術是DB的高級內容,但基本很少用了,邏輯前移,BS|CS放在B或C上了;
stored procedure,數據庫系統中,一段完成特定功能的SQL語句,編寫成類似函數的方式,可以傳參并調用,支持流程控制語句;
trigger,由事件觸發的特殊的存儲過程,如Insert數據時觸發;trigger功能雖強大,但會有性能問題;
?
?
例:
mysql> set autocommit=0;
mysql> show variables like 'autocommit';
mysql> show variables like 'tx_isolation';
mysql> select * from t;
mysql> set session transaction isolation level read committed;
?
注:
set autocommit=0;關閉自動提交;
兩個窗口均默認級別REPEATABLE-READ,
A端update t set id=4 where id=2,
A端未commit,A端查詢是改變后的狀態,B端查詢沒變化,
A端commit后,A端查詢是改變后的狀態,B端查詢沒變化,
B端commit后,B端查詢是改變后的狀態;
?
兩個窗口用READ-COMMITTED,>set session transaction isolation level read committed;
A端insert into t values(6,'ftp',28);,
A端未commit,A端查詢是改變后的狀態,B端查詢沒變化;
A端commit,A端查詢是改變后的狀態,B端查詢是改變后的狀態;
?
mysql> select * from t for update;?? #InnoDB是行級鎖,此句相當于表級鎖;使用時,用幾行加幾行鎖,且加鎖時間越短越好
mysql> commit;?? #未commit,其它窗口的mysql> update t set id=5 where id=6;更新語句會卡住
?
?
?
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。