MySQL Glossary - Transaction

MySQL官方文檔 事務相關

你好！ 這算是我的第一篇博客，之前一直有用印象筆記做記錄，今年(2020)禿然有寫博客的想法，並立了一週一篇(平均)的flag。主要是想堅守opensource的原則，更多地技術分享與交流。
關於平臺，CSDN + AdBlock 應該是我最好的選擇，站點知名度高，搜索排名靠前。
最近在複習數據庫相關知識，就寫了這篇MySQL官方文檔 事務相關博客

事務基礎概念

事務(Transaction)：事務是提交操作或回滾操作的原子單位。當一個事務包含多條操作，要麼在提交事務後所有操作都成功，要麼在回滾事務時所有操作都撤銷。
事務(Transaction)：是訪問和更新數據庫的程序執行單元；事務中可能包含一個或多個 sql 語句，這些語句要麼都執行，要麼都不執行。
由InnoDB實現的數據庫事務具有原子性，一致性，隔離性和持久性（首字母縮寫爲ACID）統稱爲屬性。
如下官方解釋：

transaction
Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.

ACID特性

ACID是事務的四個基本特性：

• 原子性（Atomicity）
• 一致性（Consistency）
• 隔離性（Isolation）
• 持久性（Durability）

ACID代表Atomicity(原子性)，Consistency(一致性)，Isolation(隔離性)和Durability(持久性)的首字母縮寫。
這些屬性都是數據庫系統所想要的，並且都與事務緊密相關。且具有事務特性的InnoDB存儲引擎遵循ACID原則。
如下官方解釋：

An acronym standing for atomicity, consistency, isolation, and durability. These properties are all desirable in a database system, and are all closely tied to the notion of a transaction. The transactional features of InnoDB adhere to the ACID principles.

原子性（Atomicity）

事務是提交操作或回滾操作的原子單位。當一個事務包含多條操作，要麼在提交事務後所有操作都成功，要麼在回滾事務時所有操作都撤銷。
如下官方解釋：

Transactions are atomic units of work that can be committed or rolled back. When a transaction makes multiple changes to the database, either all the changes succeed when the transaction is committed, or all the changes are undone when the transaction is rolled back.

一致性（Consistency）

在每次提交或回滾之後以及正處於事務處理期間，數據庫始終保持一致性狀態。如果跨多個表更新了相關數據，則查詢將看到所有舊值或所有新值，不可能存在既有新知又有新值的情況。
如下官方解釋：

The database remains in a consistent state at all times — after each commit or rollback, and while transactions are in progress. If related data is being updated across multiple tables, queries see either all old values or all new values, not a mix of old and new values.

隔離性（Isolation）

事務在進行過程中相互隔離，他們互不干擾，也不能看到彼此的未提交數據。這種隔離是通過鎖機制實現的。有經驗的用戶可以在確保事務互不干擾的情況下，調整隔離級別，犧牲較少的隔離以提高性能和併發。
如下官方解釋：

Transactions are protected (isolated) from each other while they are in progress; they cannot interfere with each other or see each other’s uncommitted data. This isolation is achieved through the locking mechanism. Experienced users can adjust the isolation level, trading off less protection in favor of increased performance and concurrency, when they can be sure that the transactions really do not interfere with each other.

持久性（Durability）

事務的結果集是持久性的：提交操作成功後，該事務所做的更改就不會受電源故障、系統崩潰、競爭狀況或許多非數據庫應用程序容易受到的其他潛在危險的影響。持久性通常包括寫入磁盤存儲，並具有一定數量的冗餘以防止寫入操作期間出現電源故障或軟件崩潰。（在InnoDB中，雙寫緩衝區[doublewrite buffer]有助於持久性。）
如下官方解釋：

The results of transactions are durable: once a commit operation succeeds, the changes made by that transaction are safe from power failures, system crashes, race conditions, or other potential dangers that many non-database applications are vulnerable to. Durability typically involves writing to disk storage, with a certain amount of redundancy to protect against power failures or software crashes during write operations. (In InnoDB, the doublewrite buffer assists with durability.)

MySQL隔離級別

隔離級別(isolation level)是數據庫處理的基礎之一。隔離是縮寫ACID中的I。隔離級別是一種平衡性能與可靠性的設置。
隔離級別由高到低爲SERIALIZABLE, REPEATABLE READ , READ COMMITTED, READ UNCOMMITTED。
InnoDB的默認隔離級別是REPEATABLE READ。
一般情況，SERIALIZABLE 和 READ UNCOMMITTED很少使用。

READ UNCOMMITTED

這是最低的事務隔離級別。查詢採用通常允許他們在等待其他事務時繼續執行的鎖策略。但是，這種額外的性能是以不可靠的結果集爲代價的，這些結果集包含已被其他事務更改但尚未提交的數據（稱爲髒讀）。請謹慎使用此隔離級別，並注意其結果可能不一致或重複。
通常，具有此隔離級別的事務僅執行查詢，而不執行插入，更新或刪除操作。
大部分人或文檔給他翻譯爲未提交讀，個人認爲翻譯成讀未提交更直觀一些。
如下官方解釋：

The isolation level that provides the least amount of protection between transactions. Queries employ a locking strategy that allows them to proceed in situations where they would normally wait for another transaction. However, this extra performance comes at the cost of less reliable results, including data that has been changed by other transactions and not committed yet (known as dirty read). Use this isolation level with great caution, and be aware that the results might not be consistent or reproducible, depending on what other transactions are doing at the same time. Typically, transactions with this isolation level only do queries, not insert, update, or delete operations.

READ COMMITTED

使用初於性能考慮放寬了事務之間的某些保護的鎖策略的一種隔離級別。事務無法看到來自其他事務未提交的數據，但是它們可以看到在當前事務啓動之後另一個事務提交的數據。
因此，一個事務永遠不會看到任何不良數據，但是它確實看到的數據可能在某種程度上取決於其他事務的時間安排。
如下官方解釋：

An isolation level that uses a locking strategy that relaxes some of the protection between transactions, in the interest of performance. Transactions cannot see uncommitted data from other transactions, but they can see data that is committed by another transaction after the current transaction started. Thus, a transaction never sees any bad data, but the data that it does see may depend to some extent on the timing of other transactions.

REPEATABLE READ

是InnoDB的默認隔離級別，當其他事務改變的時候它可以防止任一行被查詢，因此可以防止不可重複讀，但不能防止幻讀。它使用適當嚴格的lock策略，這樣，一個事務的所有查詢都是從相同的數據快照中查的，也就是事務開始時的數據。
如下官方解釋：

The default isolation level for InnoDB. It prevents any rows that are queried from being changed by other transactions, thus blocking non-repeatable reads but not phantom reads. It uses a moderately strict locking strategy so that all queries within a transaction see data from the same snapshot, that is, the data as it was at the time the transaction started.

SERIALIZABLE

隔離級別使用最保守的lock策略，該級別可以避免“髒讀”、“不可重複讀”和“幻讀”。代價是處理事務的吞吐量低，嚴重浪費數據庫的性能。
這是SQL標準指定的默認隔離級別。
實際上，很少需要這種嚴格程度，因此InnoDB的默認隔離級別是REPEATABLE READ。
如下官方解釋：

The isolation level that uses the most conservative locking strategy, to prevent any other transactions from inserting or changing data that was read by this transaction, until it is finished. This way, the same query can be run over and over within a transaction, and be certain to retrieve the same set of results each time. Any attempt to change data that was committed by another transaction since the start of the current transaction, cause the current transaction to wait.
This is the default isolation level specified by the SQL standard. In practice, this degree of strictness is rarely needed, so the default isolation level for InnoDB is the next most strict, REPEATABLE READ.