事務ACID特性
原子性：事務要么同時成功，要么同時失敗，事務的原子性通過undo log日志保證
一致性：業務代碼要拋出報錯，讓數據庫回滾
隔離性：事務并發執行時，他們內部操作不能互相干擾
持久性：事務一旦提交，對數據庫的改變就是永久性的。通過redo log日志保證
隔離性
InnoDB引擎中的隔離機制的通過MySQL的鎖和MVCC機制實現，提供四種隔離級別，越高隔離性越好，分別是讀未提交（臟讀）、讀已提交（不可重復讀）、可重復讀（贓寫）、串行
讀取未提交：所有事務都可以看到其他未提交事務的執行結果。
臟讀：是某一事務A讀取到了事務B修改未提交的數據。
讀以提交?：一個事務只能看見已經提交事務所做的改變。解決：解決讀未提交事務A修改數據，事務B讀取數據，事務B讀取的數據是原始數據（不是事務A修改后的數據。
不可重復讀：在一個事務內，多次讀取同一個數據，卻返回了不同的結果，有其他事務對這段數據進行了修改并提交。
?可重讀：事務讀取數據只會讀到訪問數據第一個版本的數據。
解決：事務A多次查看數據中事務B讀取數據提交，數據是最初打開事務看到的數據。
贓寫：事務A查看數據永遠是第一次查看的數據，事務B修改數據+500，事務A修改數據+200，就會覆蓋之前修改的數據。
可重讀帶來的臟寫的解決方案：樂觀鎖，在數據庫中修改可重讀的實現機制：通過mvvc機制，會記錄當版本的數據。
可串行：事務會等待其他事務執行結束，否則會阻塞。
解決：臟讀、不可重復度、贓寫。
持久性
Buffer Pool內存寫完了，會寫redo log 日志記錄在那個表修改了什么。
即便MySQL掛了，我們還可以根據redo log 對數據進行恢復。
redo log是順序寫的，寫入速度很塊，恢復速度也快。
MySQL的事務ACID特性有哪些？
原子性、一致性、隔離性、持久性
原子性：事務要么同時成功，要么同時失敗，事務的原子性通過undo log日志保證
一致性：業務代碼要拋出報錯，讓數據庫回滾
隔離性：事務并發執行時，他們內部操作不能互相干擾
持久性：事務一旦提交，對數據庫的改變就是永久性的。通過redo log日志保證
InnoDB引擎中的隔離機制有哪些？
讀未提交、讀已提交、可重讀、串行化
InnoDB引擎中的隔離機制是如何實現的？
InnoDB引擎中的隔離機制的通過MySQL的鎖和MVCC機制實現
讀未提交是什么？帶來什么問題？
讀未提交是事務可以讀取到其他事務修改還未提交的數據。
會帶臟讀的問題，讀取到其他事務修改未提交的數據，然后其他事務回滾，就會導致讀取的數據和數據庫不一致。
讀以提交是什么？解決什么問題？帶來什么問題？
讀已提交只能讀到其他事務已提交的數據。
可能會帶來不重復讀問題，讀取幾次間隔，其他多個事務修改提交。
可重讀是什么？解決什么問題？帶來什么問題？
可重讀是多次讀取數據只能讀到數據第一個版本。
解決了讀已提交帶來的不可重讀問題。
可能帶來贓寫問題，多個事務回去數據修改，會覆蓋之前的修改結果。
可重讀可以用樂觀鎖等方式解決。
可串行是什么？解決什么問題？帶來什么問題？
隔離機制可穿行是事務操作數據會等到其他事務操作完成，
解決了臟讀，不可重讀，贓寫問題，但是在高并發的時候會影響性能。
查詢數據需要使用事務嗎？
如果是可重讀事務隔離性，保證所有數據的都是同時性。
對并發性比較高使用讀以提交隔離級別。
傳統公司使用讀以提交隔離級別
為什么要寫先到redo日志中？
redo日志是一個文件是按照磁盤順序寫的，速度快。
磁盤文件idb是多個文件在磁盤的不同位置，實現不了磁盤順序寫。
三大范式
?事務與鎖
事務ACID特性
原子性：事務要么同時成功，要么同時失敗，事務的原子性通過undo log日志保證
一致性：業務代碼要拋出報錯，讓數據庫回滾
隔離性：事務并發執行時，他們內部操作不能互相干擾
持久性：事務一旦提交，對數據庫的改變就是永久性的。通過redo log日志保證
原子性
一致性
隔離性
InnoDB引擎中的隔離機制的通過MySQL的鎖和MVCC機制實現，提供四種隔離級別，越高隔離性越好。
讀未提交：臟讀
讀已提交：不可重復讀
可重復讀：贓寫
串行：
MySQL設置、查看隔離級別?
read-uncommitted
read-committed
repeatable read
serializable-- 如何查看事務隔離
SELECT @@global.transaction_isolation;
-- 設置事務隔離性
set global transaction isolation level 隔離性讀取未提交
讀取未提交：所有事務都可以看到其他未提交事務的執行結果
帶來的問題：臟讀是某一事務A讀取到了事務B未提交的數據。
臟讀情況：事務A修改數據，事務B讀取數據，事務A回滾數據，則會導致事務B讀取的是臟數據。
讀以提交?
讀以提交?：一個事務只能看見已經提交事務所做的改變。
解決：解決讀未提交事務A修改數據，事務B讀取數據，事務B讀取的數據是原始數據（不是事務A修改后的數據。
帶來的問題：不可重復讀：在一個事務內，多次讀取同一個數據，卻返回了不同的結果。
因為在該事務間隔讀取數據的期間，有其他事務對這段數據進行了修改并提交
可重讀
不可重復讀：在一個事務內，多次讀取同一個數據，卻返回了不同的結果。
因為在該事務間隔讀取數據的期間，有其他事務對這段數據進行了修改并提交
解決：事務A多次查看數據中事務B讀取數據提交，數據是最初打開事務看到的數據。
帶來的問題：事務A查看數據永遠是第一次查看的數據，事務B修改數據+500，事務A修改數據+200，就會覆蓋之前修改的數據。
可重讀的實現機制
可重讀帶來的臟寫的解決方案：樂觀鎖
事務A獲取數據 0，事務B修改數據 +100，事務A修改數據 +200，會覆蓋事物B修改的數據。
BEGIN; update account set blance=blance+100 where id=1 and version=2;update account set version=2 where id=1 ; COMMIT;代碼修改 判斷獲取的版本是第一版本才修改。 update account set blance=blance+200 where id=1 and version=1;
可重讀帶來的臟寫的解決方案：在數據庫中修改
在數據庫修改數據獲得最新的數據。
只限于這一張表。
可串行化
-- 事務一 BEGIN; SELECT * FROM account WHERE id=1; COMMIT;-- 事務二 BEGIN; UPDATE account SET balance=balance+500 WHERE id=1; COMMIT;
持久性
Buffer Pool內存寫完了，然后會寫redo log，redo log 日志記錄在那個表修改了什么。
即便MySQL掛了，我們還可以根據redo log 對數據進行恢復。
redo log是順序寫的，寫入速度很塊，恢復速度也快。
MySQL的事務ACID特性有哪些？
InnoDB引擎中的隔離機制有哪些？
查詢數據需要使用事務嗎？
如果是可重讀事務隔離性，保證所有數據的都是同時性。
對并發性比較高使用RC隔離級別。
傳統公司使用RR隔離級別
為什么要寫先到redo日志中？
redo日志是按照磁盤順序寫
磁盤文件idb是多個文件在磁盤的不同位置，實現不了磁盤順序寫。
方法)
