7.1? 認識事務

7.1.1 概述

在事務中的操作， 要么都做修改， 要么都不做， 這就是事務的目的，也是事務模型區別與文件系統的重要特征之一。

A 原子性，

C 一致性，

I 隔離性，也可稱為并發控制， 可串行化， 鎖

每個讀寫事務的對象對其他事務的操作對象能相互分離

D 持久性

7.1.2 分類

扁平事務

帶有保存點的扁平事務

鏈事務, ?可視為保存點模式的一種變種。

嵌套事務， 是一個層次結構框架

分布式事務

7.2 事務的實現

原子性，一致性，持久性通過數據庫的 redo log 和 undo Log 來完成。 redo log 稱為重做日志， 用來保證事務的原子性和持久性。 undo log 用來保證事務的一致性。

redo 和 undo 不是 逆過程。redo 恢復提交事務修改的頁操作， 而 undo 回滾行記錄到某個特定版本。兩者記錄的內容不同， redo 通常是物理日志， 記錄的是頁的物理修改操作。 undo 是邏輯日志， 根據每行記錄進行記錄。

7.2.1 redo

1 基本概念

重做日志用來實現事務的持久性， 其由兩部分組成： 一是內存中的重做日志緩存（redo log buffer），其是易失的； 二是日志文件（redo log file），其是持久的。

InnoDB 事務引擎，通過 Force Log at Commit 機制實現事務的持久性， 即當事務提交（commit）時， 必須先將該事務的所有日志寫入到重做日志文件進行持久化， 待事務的 commit 操作完成才算完成。// 這部分寫的有問題， 沒分清 重做日志是只有 redo log 還是 redo log 和 undo log 兩個。

redo log 基本都是順序寫的， 在數據庫運行時不需要對 redo log 的文件進行讀取操作， 而 undo log 是需要隨機讀寫的。

為了確保每次日志都寫入重做日志文件， 在每次將重做日志緩沖寫入重做日志文件后， InnoDB 引擎都需要調用一次 fsync 操作。

由于fsync 的效率取決于磁盤的性能， 因此磁盤的性能決定了事務提交的性能， 也就是數據庫的性能. // 待理解，是說數據庫的性能取決于事務的性能？

參數 innodb_flush_log_at_trx_commit ，默認為 1 。 用來控制重做日志刷新到磁盤的策略。

0 表示提交時不進行寫入重做日志操作，這個操作僅在 master thread 中完成， 而在 master thread 中每一秒會進行一次重做日志的 fsync 操作。//最快 ?

1 表示會將重做日志緩沖中的日志寫入文件， 并調用一次 fsync 操作。 //最慢, 在執行 commit 時將重做日志緩沖同步到磁盤

2 表示事務提交時將重做日志寫入重做日志文件， 但僅寫入文件系統的緩存中， 不進行 fsync 操作。//中間 將重做日志異步寫到磁盤，即寫到文件系統的緩沖， 不保存執行 commit 時肯定會寫入重做日志文件。

2 log block

在 InnoDB 中，重做日志都是以 512 字節進行存儲的。?

日志塊由三部分組成， 依次為日志塊頭（log block header）, 日志內容（log body）， 日志塊尾（log block tailer）。

3 log group

4 重做日志格式

7.2.2 undo

1 基本概念

事務的回滾， 需要 undo

undo 是邏輯日志， 因此只是將數據庫邏輯地恢復到原來的樣子。 所有修改都被邏輯地取消了， 但是數據結構和頁本身在回滾之后可能大不相同。因此不能將一個頁回滾到事務開始的樣子， 因為這樣會影響其他事務正在進行的工作。

除了回滾操作， undo 的另一個作用是 mvcc ，即在 InnoDB 引擎中 MVCC 的實現是通過 undo 來完成。// 待擴充

undo log 會產生 redo log ， 也就是 undo log 的產生會伴隨著 redo log 的產生， 因為undo log 也需要持久性保護。

2 ?undo 存儲管理

show engine innodb status\G

history list length 代表了 undo log 的數量。

3 undo log 格式

undo log 分為：

insert undo log

update undo log

4 查看 undo 信息

//mysql 5.6 的 information_schema 數據庫中，

//找不到表 INNODB_TRX_ROLLBACK_SEGMENT, INNODB_TRX_UNDO

7.2.3 purge

delete 和 update 操作可能并不直接刪除原有的數據。

delete from t where a ?= 1;

表 t 上 列 a 有聚集索引（主鍵）， 列 b 上有輔助索引。 對于 delete 操作， 僅是將主鍵列等于 1 的記錄 delete flag 設置為 1， 記錄并沒有被刪除， 即 還是存在 B+ 數中。 其次， 對輔助索引上 a 等于 1 ， b 等于 1 的記錄同樣沒做任何處理， 針織沒有產生 undo log 。 真正的刪除這行記錄的操作被 “延時”了， 最終在 purge 操作中完成。

purge 用來完成最終的 delete 和 update 的操作。 因為 innoDB 存儲引擎支持 MVCC， 所以記錄不能在事務提交時立即處理，這時其他事務可能正在引用這行， 故 innoDB 需要保存記錄之前的版本。 是否可以刪除通過 purge 判斷。

為了節省存儲空間， 一個頁上允許多個事務的 undo log 存在。

全局動態參數 innodb_purge_batch_size 用來設置每次 purge 操作需要清理的 undo ?page 數量， 從 1.2 版本開始，默認值為 300.?

全局動態參數 innodb_max_purge_lag 用來控制history list 的長度。默認值為 0

7.2.4 group commit

一次 fsync 可以刷新確保多個事務日志被寫入文件， 事務提交時會進行兩個階段的操作：

1） 修改內存中事務對應的信息， 并且將日志寫入重做日志緩沖。

2）調用 fsync 將確保日志都從重做日志緩沖寫入磁盤。

步驟2）相對 1） 是一個較慢的過程， 因為要與磁盤打交道。

保證 二進制日志的寫入順序和 InnoDB 的事務提交順序，為了備份和恢復的需要。

7.3 事務控制語句

commit 和commit work 語句基本一致， 都用來提交事務。 不同之處 commit work 用來控制事務結束后的行為是 chain 還是 release。 若果是 chain 方式， 那么事務變成了 鏈事務。

通過用 completion_type 來控制是否是鏈事務

默認為 0 ， 沒有任何操作， commit 和 commit work 等價

設置為 1 ， commit work 自動開啟一個鏈事務， 不用顯示的 begin?

設置為 2 ， commit work 等同與 commit and release。 在事務提交胡會自動斷開與服務器的連接

7.4 隱式提交的 SQL 語句

執行完相應語句后， 會有一個隱式的 commit 操作。此時 執行 rollback 將不可以回退

7.5 對于事務操作的統計

show global status like 'com_commit'

7.6 事務的隔離級別

READ UNCOMMITTED

READ COMMITTED 除了唯一性的約束檢查及外鍵約束的檢查需要 gap lock, InnoDB 引擎不會使用 gap lock 的鎖算法。

REPEATABLE READ ?使用next-key lock 鎖算法， 避免幻讀問題產生。

SERIALIZABLE 在此級別, InnoDB 會對每個 select 語句自動加上 lock in share mode 。 且主要用于 InnoDB 存儲引擎的分布式事務。

7.7 分布式事務

7.7.1 MySql 數據庫分布式事務

例子： 北京的張三轉 1000 塊錢到 上海的李四賬戶

在 PHP 中的實現：http://php.net/manual/zh/mysqlnd-ms.quickstart.xa_transactions.php

7.7.2 內部 XA 事務

另一種分布式事務：在存儲引擎與插件之間，或在存儲引擎與存儲引擎之間。

例如：寫 innodb redo 日志和 binlog 日志，要保持一致性時用到

7.8 不好的事務習慣

7.8.1 在循環中提交

7.8.2 使用自動提交

使用 start transaction, begin 來顯示地開啟一個事務。 在顯示開啟事務后， 在默認設置下（completion_type 等于 0）， mysql 會自動執行 set autocommit = 0 的命令， 并在 commit 或 rollback 結束一個事務后執行 set autocommit = 1.

7.8.3 使用自動回滾

7.9 長事務

將長事務分為若干短事務來執行。

例如：在銀行系統中， 將一億用戶添加利息的操作，分為沒十萬個一個事務。來完成。好處是 1 不用完全回滾；2 知道進度。