我的理解：同一根繩上的螞蚱，要活一起活，要死一起死，事務就是併發控制的單位。
a：原子性（atomicity） 事務中的操作要麼都不做，要麼就全做。
c：一致性（consistency） 事務執行的結果必須是從資料庫從乙個一致性狀態轉換到另乙個一致性狀態。
i：隔離性（isolation）乙個事務的執行不能被其他事務干擾
d：永續性（durability）
也稱永久性，指乙個事務一旦提交，它對資料庫中的資料的改變就應該是永久性的。接下來的其它操作或故障不應該對其執行結果有任何影響。
1、髒讀：髒讀是指在乙個事務處理過程裡讀取了另乙個未提交的事務中的資料。
2、不可重複讀：乙個事務兩次讀取同一行的資料，結果得到不同狀態的結果，
中間正好另乙個事務更新了該資料，兩次結果相異，不可被信任。通俗來講就是：
事務t1在讀取某一資料，而事務t2立馬修改了這個資料並且提交事務給資料庫，
事務t1再次讀取該資料就得到了不同的結果，傳送了不可重複讀。
3、幻讀（虛讀）：乙個事務執行兩次查詢，
第二次結果集包含第一次中沒有或某些行已經被刪除的資料，造成兩次結果不一致，只是另乙個事務在這兩次查詢中間插入或刪除了資料造成的。
通俗來講就是：例如事務t1對乙個表中所有的行的某個資料項做了從「1」修改為「2」的操作，這時事務t2又對這個表中插入了一行資料項，而這個資料項的數值還是為「1」並且提交給資料庫。
而操作事務t1的使用者如果再檢視剛剛修改的資料，會發現還有一行沒有修改，其實這行是從事務t2中新增的，就好像產生幻覺一樣，這就是發生了幻讀
1.讀未提交（read uncommitted）引發髒讀（讀取了未提交的資料）
2.讀已提交（read committed）這是大多數資料庫系統預設的隔離級別，但不是mysql預設的只能看見已經提交事務所做的改變引發不可重複讀，不可重讀讀意味著我們同一事務執行完全相同的select語句時可能看到不一樣的結果。
導致這種情況的原因可能有：
(1)有乙個交叉的事務有新的commit，導致了資料的改變;
(2)乙個資料庫被多個例項操作時,同一事務的其他例項在該例項處理其間可能會有新的commit 多個commit提交時，唯讀一次出現結果不一致
3、重複讀（repeatable read）
重複讀，就是在開始讀取資料（事務開啟）時，不再允許修改操作。重複讀可以解決不可重複讀問題。應該明白的一點就是，不可重複讀對應的是修改，即update操作。但是可能還會有幻讀問題。
因為幻讀問題對應的是插入insert操作，而不是update操作。採用serializable可以解決幻讀問題
4.可序列化（serializable）
serializable 是最高的事務隔離級別，在該級別下，事務序列化順序執行，可以避免髒讀、不可重複讀與幻讀。但是這種事務隔離級別效率低下，比較耗資料庫效能，一般不使用。
事務通常以begin（start） transaction 開始，以commit 或 rollback 結束。
commit表示提交，將事務中所有對資料庫的更新寫會到磁碟的物理資料庫中，事務正常結束。
rollback表示回滾，即在事務執行的過程中發生了某種故障，事務不能繼續進行，系統將事務中對資料庫的所有以完成的操作全部撤消，滾回到事務開始的狀態。
面試題問答
區別通過作用體現 作用 用於呼叫陣列的每個元素，並將元素傳遞給 函式,函式的三個分別是value，index，arr 陣列本身 不足 不能同時遍歷多個集合，在遍歷的時候無法修改和刪除集合資料，方法不能使用break，continue語句跳出迴圈，或者使用return從函式體返回，對於空陣列不會執行 ...
企業面試題 最常問的MySQL面試題集合（三）
延伸 對使用者而言，分割槽表是乙個獨立的邏輯表，但是底層mysql將其分成了多個物理子表，這對使用者來說是透明的，每乙個分割槽表都會使用乙個獨立的表檔案。如圖所示 mysql將表分成多個物理字表，但php客戶端並無感知，仍然認為操作的是乙個表。建立表時使用partition by子句定義每個分割槽存...
java spring 事務面試題
1 spring事務控制放在service層，在service方法中乙個方法呼叫service中的另乙個方法，預設開啟幾個事務？spring的事務傳播方式預設是propagation required，判斷當前是否已開啟乙個新事務，有則加入當前事務，否則新開乙個事務 如果沒有就開啟乙個新事務 所以答...