三範式
ACID
原子性(Atomicity):a向b轉了十塊錢，一定是a轉出，b轉入，不可能存在a轉出，但b沒有轉入.(轉賬操作是一個不可分割的操作，要麼轉失敗，要麼轉成功,不能存在中間狀態，也就是轉了一半的這種情況)【要麼全做，要麼全不做】
隔離性(Isolation)：a向b轉了十塊錢，a向c轉了十塊錢，不可能出現b的賬戶裏多了20塊，即a轉給c的，卻轉到了b的賬戶上。【兩個操作互不影響】
一致性(Consistency)：無論a，b之間如何轉錢，A和b的總金額總是要保持不變的【最終數據一致性】
持久性(Durability):對於轉賬的交易記錄，需要永久保存【事務提交後的數據要能永久保存】
事務隔離機制的實現原理
事務（id爲80），添加了數據1，並提交了。事務81，82，200都開啓了事務並對數據1進行了相應的修改，但都未進行事務的提交（此時81，82，200都處於m_ids【他是readview裏面的屬性，是用來記錄那些事務是活躍的】的數組裏面），此時如果事務300過來了，它的事務隔離級別是讀已提交，它會從上往下開始找尋版本鏈，發現200，82，81都在m_ids裏面，所有都不會從裏面讀數據，往下走是80，它不在m_ids裏面，故讀到了80裏面的數據1.
事務隔離級別
讀未提交
-[當前事物能夠看到別的事物中未提交的數據(讀的並不是最終數據)，我們稱這種現象爲髒讀]
張三開啓事務：先將a設爲5000，又將a設爲2000，提交事務。
李四先讀到了5000(髒讀)，又讀到了2000
【髒讀現象演示】
髒讀:當前事務可以查看到別的事務未提交的數據(側重點在於別的事務未提交).
讀已提交
不可重讀(一次事務中兩次對同一行數據讀取出來，查詢結果是不一樣的)(數據讀錯了)
【不可重讀現象演示】
不可重複讀:不可重讀的側重點在於更新修改數據,表示在同一事務中,查詢相同的數據範圍時,同一個資源莫名的改變了。(mysql官方文檔也把它歸爲幻讀）
可重讀
它解決了不可重讀的問題
可重讀的實現原理
但是你可能會有個問題，事物的隔離性是由鎖來實現的，事務1執行更新語句時，事務1中應該對數據增加了寫鎖【排他鎖】，但在事務二中仍然可以進行查詢操作？，可是寫鎖是排他鎖，在事務1已經添加了寫鎖情況下，爲什麼事務二還可以讀呢？這就與一致性非鎖定讀的機制有關，它提高了數據庫的併發性，既【如果當前行被加了排他鎖，那麼當需要讀取行數據時則不會等待行上的鎖釋放，而是會去讀取一個快照數據】。
上圖展示了innodb中一致性非鎖定讀的過程,之所以稱其爲非鎖定讀,是因爲它不需要等待被訪問行上的排他鎖的釋放,而上圖中的快照的實現是由事日誌所對應的undo來完成,其實快照就是該行對應的之前的版本的數據【即歷史數據】,一行記錄可能有不止一個快照數，並不是所有隔離級別都使用了一致性非鎖定讀,在“可重讀和讀已提交的級別下,innodb使用了一致性非鎖定讀,但是在這兩個級別中,對於快照數據的定義也不相同,在可重級別下,快照數據是指當前事務開始時數據的樣子,所以,在剛纔的示例中,事務2中t1表對應的第二條記錄的t1str的值一直都是2,因爲在事務2開始的時候,其值就是2,這是其可重讀的特性,但是在讀提交的隔離級別下，由於對於快照的定義不同,所以顯示的現象也不同。
【幻讀現象演示】
幻讀 ：幻讀的側重點在於新增和刪除,表示在同一事務中,使用相同的查詢語句,第二次查詢時,莫名的多出了一些之前不存在數據,或者莫名的不見了一些數據。
幻讀(在一次事務中讀出來的數據突然多了或者少了)(數據讀多了，或者讀少了)，
串行化
解決幻讀問題演示
實現原理：
事務的隔離性是由鎖來實現的
事務一更新表1數據時會施加寫鎖，事務二，對錶一請求讀鎖時會被阻塞(出現請求鎖超時的情況)，只有當事務一提交了事務，他的鎖釋放了，事物二才能讀出數據
它通過施加讀寫鎖，雖然解決了幻讀問題，但確使數據庫失去了併發能力。