官方文件
Sqlserver https://learn.microsoft.com/en-us/sql/t-sql/statements/set-transaction-isolation-level-transact-sql?view=sql-server-ver16
Mysql https://dev.mysql.com/doc/refman/5.7/en/glossary.html#glos_isolation_level
Oracle https://docs.oracle.com/en/database/oracle/oracle-database/19/cncpt/data-concurrency-and-consistency.html#GUID-2A0FDFF0-5F72-4476-BFD2-060A20EA1685
Postgresql https://www.postgresql.org/docs/14/transaction-iso.html

讀提交(READ COMMITTED),簡稱RC:根據資料庫的多版本併發控制(MVCC)機制，不同時刻啟動的事務會有不同的一致性讀檢視consistent read view，在“讀提交”隔離級別下，這個檢視是在每個SQL語句開始執行的時候建立的,其他事務可以在當前事務的各個語句之間更改資料。oracle，sqlserver，postgresql(show transaction_isolation;)的隔離級別預設就是讀提交。隔離級別比可重複讀(REPEATABLE READ)要低一點，併發級別比可重複讀(REPEATABLE READ)要高一點。

可重複讀(REPEATABLE READ)，簡稱RR:根據資料庫的多版本併發控制(MVCC)機制，不同時刻啟動的事務會有不同的一致性讀檢視consistent read view，在“可重複讀”隔離級別下，這個檢視是在事務啟動時建立的，整個事務存在期間都用這個檢視,其他任何事務都不能在當前事務完成之前修改由當前事務讀取的資料。mysql(select @@global.tx_isolation)的隔離級別預設就是可重複讀,oracle沒有這個隔離級別的概念。

未提交讀(READ UNCOMMITED):髒讀，一個事務還沒提交時，它做的變更就能被別的事務看到；是最低的隔離級別，併發級別最高。

可序列化(SERIALIZABLE):在當前事務完成之前，其他事務不能使用當前事務中任何語句讀取的鍵值插入新行。注意其中的關鍵字任何語句，意思就是讀也會鎖定行，也就是說對於同一行記錄，“寫”會加“寫鎖”，“讀”會加“讀鎖”。當出現讀寫鎖衝突的時候，後訪問的事務必須等前一個事務執行完成，才能繼續執行。限制最多的隔離級別，因為它鎖定了當前事務涉及到的所有行，當前事務完成之前會一直保持這些行範圍鎖，併發級別最低。

併發級別從高到低排序：未提交讀(READ UNCOMMITED)--->讀提交(READ COMMITTED)--->可重複讀(REPEATABLE READ)--->可序列化(SERIALIZABLE)

其中比較容易混淆的就是讀提交(READ COMMITTED)和可重複讀(REPEATABLE READ)，讀提交(READ COMMITTED)和可重複讀(REPEATABLE READ)的區別就是：讀提交(READ COMMITTED)的一致性讀檢視consistent read view是在每個SQL語句開始執行的時候建立的，可重複讀(REPEATABLE READ)的一致性讀檢視consistent read view是在事務啟動時建立的。其中Sqlserver、Mysql、PG都有這兩種隔離級別，Oracle只有讀提交(READ COMMITTED)但是沒有可重複讀(REPEATABLE READ)的概念，oracle的Read consistency(select才會產生)和Read current(dml才會產生)其實都是讀提交隔離級別。Read consistency,當查詢開始的時候oracle將確立一個時間點，凡是在這個時間點以前提交的資料oracle將能看見，之後提交的資料將不能看見。但查詢的時候可能遇上這樣的情況，該塊中資料已經被修改了，沒有提交，或者提交的時間點比查詢開始的時間晚，則oracle為了保證讀的一致性，需要去回滾段獲取該塊中變化前的資料。Read current，就是看到當前的block中的內容是什麼就是什麼，跟時間點無關，不能去回滾段獲取之前的資料。假如當前block中資料是被其他的session更改過還沒有提交，那麼則看到當前狀態資料被其他session鎖定，則dml需要等待其他session結束(提交或回滾)，這樣這個dml就會被堵塞。更新資料都是先讀後寫的，而這個讀，只能讀當前的值，稱為“當前讀”（current read），總是讀取已經提交完成的最新版本。

隔離級別和大事務在主從節點的延遲是否有重大關係，個人認為關係不大，主要和同步邏輯相關相關，如果主庫上必須等所有事務執行完成才會寫入日誌，並且日誌檔案需要傳輸到備庫再在備庫應用完這些日誌，才能完成同步，這樣主從的延遲就是：日誌從主庫傳輸到備庫+日誌在備份的應用時間。所以說如果一個主庫上的事務執行 10 分鐘，那這個事務是否就會導致從庫延遲 10 分鐘？這句話的理解需要針對不同資料庫來說，針對sqlserver和oracle而言就不會延遲10分鐘，因為sqlserver和oracle主節點的事務不是非要提交了才會寫入日誌且日誌也不需要等待到寫到一定大小才會傳輸到從節點，針對mysql是對的，因為mysql的同步用的是bin-log，bin-log一定都是提交之後的日誌檔案且bin-log檔案切換到下個bin-log檔案時，上一個bin-log檔案才會傳輸到從節點

**Sqlserver**
READ COMMITTED
Specifies that statements cannot read data that has been modified but not committed by other transactions. This prevents dirty reads. Data can be changed by other transactions between individual statements within the current transaction, resulting in nonrepeatable reads or phantom data. This option is the SQL Server default.
指定語句不能讀取已由其他事務修改但尚未提交的資料。 這樣可以避免髒讀。 其他事務可以在當前事務的各個語句之間更改資料，從而產生不可重複讀取和虛擬資料。 該選項是 SQL Server 的預設設定。

REPEATABLE READ
Specifies that statements cannot read data that has been modified but not yet committed by other transactions and that no other transactions can modify data that has been read by the current transaction until the current transaction completes.
Shared locks are placed on all data read by each statement in the transaction and are held until the transaction completes. This prevents other transactions from modifying any rows that have been read by the current transaction. Other transactions can insert new rows that match the search conditions of statements issued by the current transaction. If the current transaction then retries the statement it will retrieve the new rows, which results in phantom reads. Because shared locks are held to the end of a transaction instead of being released at the end of each statement, concurrency is lower than the default READ COMMITTED isolation level. Use this option only when necessary.
指定語句不能讀取已由其他事務修改但尚未提交的行，並且指定，其他任何事務都不能在當前事務完成之前修改由當前事務讀取的資料。
對事務中的每個語句所讀取的全部資料都設定了共享鎖，並且該共享鎖一直保持到事務完成為止。 這樣可以防止其他事務修改當前事務讀取的任何行。 其他事務可以插入與當前事務所發出語句的搜尋條件相匹配的新行。 如果當前事務隨後重試執行該語句，它會檢索新行，從而產生虛擬讀取。 由於共享鎖一直保持到事務結束，而不是在每個語句結束時釋放，因此併發級別低於預設的 READ COMMITTED 隔離級別。 此選項只在必要時使用。

**Mysql**
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.
    When a transaction with this isolation level performs UPDATE ... WHERE or DELETE ... WHERE operations, other transactions might have to wait. The transaction can perform SELECT ... FOR UPDATE, and LOCK IN SHARE MODE operations without making other transactions wait. 
     一種使用鎖定策略的隔離級別，為了提高效能，放寬事務之間的一些保護。事務看不到其他事務未提交的資料，但可以看到當前事務啟動後另一個事務提交的資料。因此，事務永遠不會看到任何壞資料，但它確實看到的資料可能在某種程度上取決於其他事務的時間。
    當具有此隔離級別的事務執行 UPDATE ... WHERE 或 DELETE ... WHERE 操作時，其他事務可能必須等待。該事務可以執行 SELECT ... FOR UPDATE 和 LOCK IN SHARE MODE 操作，而無需讓其他事務等待。

REPEATABLE READ
    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.
    When a transaction with this isolation level performs UPDATE ... WHERE, DELETE ... WHERE, SELECT ... FOR UPDATE, and LOCK IN SHARE MODE operations, other transactions might have to wait. 
    InnoDB 的預設隔離級別。它可以防止查詢的任何行被其他事務更改，從而阻止不可重複讀取，但不會阻止幻讀。它使用適度嚴格的鎖定策略，以便事務中的所有查詢都看到來自同一快照的資料，即事務開始時的資料。
    當具有此隔離級別的事務執行 UPDATE ... WHERE、DELETE ... WHERE、SELECT ... FOR UPDATE 和 LOCK IN SHARE MODE 操作時，其他事務可能必須等待。

**Oracle**
Oracle Database provides the transaction isolation levels:
Read Committed Isolation Level
Serializable Isolation Level
Read-Only Isolation Level

Read Committed Isolation Level
In the read committed isolation level, every query executed by a transaction sees only data committed before the query—not the transaction—began.
This isolation level is the default. It is appropriate for database environments in which few transactions are likely to conflict.
A query in a read committed transaction avoids reading data that commits while the query is in progress. For example, if a query is halfway through a scan of a million-row table, and if a different transaction commits an update to row 950,000, then the query does not see this change when it reads row 950,000. However, because the database does not prevent other transactions from modifying data read by a query, other transactions may change data between query executions. Thus, a transaction that runs the same query twice may experience fuzzy reads and phantoms.
在讀取已提交隔離級別中，事務執行的每個查詢只能看到在查詢開始之前提交的資料，而不是事務開始。
這個隔離級別是預設的。它適用於很少有事務可能發生衝突的資料庫環境。
讀取提交事務中的查詢避免讀取在查詢進行時提交的資料。例如，如果一個查詢正在掃描一個百萬行的表，並且如果另一個事務提交了對第 950,000 行的更新，那麼查詢在讀取第 950,000 行時不會看到此更改。但是，由於資料庫不會阻止其他事務修改查詢讀取的資料，因此其他事務可能會在查詢執行之間更改資料。因此，兩次執行相同查詢的事務可能會遇到模糊讀取和幻像。
Read Consistency in the Read Committed Isolation Level
The database provides a consistent result set for every query, guaranteeing data consistency, with no action by the user.
An implicit query, such as a query implied by a WHERE clause in an UPDATE statement, is guaranteed a consistent set of results. However, each statement in an implicit query does not see the changes made by the DML statement itself, but sees the data as it existed before changes were made.
If a SELECT list contains a PL/SQL function, then the database applies statement-level read consistency at the statement level for SQL run within the PL/SQL function code, rather than at the parent SQL level. For example, a function could access a table whose data is changed and committed by another user. For each execution of the SELECT in the function, a new read-consistent snapshot is established. 
讀取提交隔離級別中的讀取一致性
資料庫為每次查詢提供一致的結果集，保證資料的一致性，無需使用者進行任何操作。
隱式查詢（例如 UPDATE 語句中的 WHERE 子句隱含的查詢）保證獲得一致的結果集。但是，隱式查詢中的每個語句都看不到 DML 語句本身所做的更改，而是看到更改前存在的資料。
如果 SELECT 列表包含 PL/SQL 函式，那麼資料庫會在語句級別為 PL/SQL 函式程式碼內執行的 SQL 應用語句級別的讀取一致性，而不是在父 SQL 級別。例如，一個函式可以訪問一個表，該表的資料已被另一個使用者更改和提交。對於函式中的每一次 SELECT 執行，都會建立一個新的讀一致性快照。

read committed isolation level
An isolation level that guarantees that a query executed by a transaction sees only data committed before the query—not the transaction—began.
Oracle Database offers the read committed (default) and serializable isolation levels. Also, the database offers a read-only mode.
一種隔離級別，它保證事務執行的查詢只能看到在查詢（而不是事務）開始之前提交的資料。
Oracle 資料庫提供已提交讀（預設）和可序列化隔離級別。此外，資料庫提供只讀模式。

**PG**
Read Committed Isolation Level
Repeatable Read Isolation Level
Serializable Isolation Level

Read Committed is the default isolation level in PostgreSQL. When a transaction uses this isolation level, a SELECT query (without a FOR UPDATE/SHARE clause) sees only data committed before the query began; it never sees either uncommitted data or changes committed during query execution by concurrent transactions. In effect, a SELECT query sees a snapshot of the database as of the instant the query begins to run. However, SELECT does see the effects of previous updates executed within its own transaction, even though they are not yet committed. Also note that two successive SELECT commands can see different data, even though they are within a single transaction, if other transactions commit changes after the first SELECT starts and before the second SELECT starts.
Read Committed 是 PostgreSQL 中的預設隔離級別。當事務使用此隔離級別時，SELECT 查詢（沒有 FOR UPDATE/SHARE 子句）只能看到在查詢開始之前提交的資料；它永遠不會看到未提交的資料或併發事務執行查詢期間提交的更改。實際上，SELECT 查詢看到的是查詢開始執行時的資料庫快照。然而，SELECT 確實看到了在它自己的事務中執行的先前更新的影響，即使它們尚未提交。另請注意，如果其他事務在第一個 SELECT 開始之後和第二個 SELECT 開始之前提交更改，則兩個連續的 SELECT 命令可以看到不同的資料，即使它們在單個事務中也是如此

The Repeatable Read isolation level only sees data committed before the transaction began; it never sees either uncommitted data or changes committed during transaction execution by concurrent transactions. (However, the query does see the effects of previous updates executed within its own transaction, even though they are not yet committed.) This is a stronger guarantee than is required by the SQL standard for this isolation level, and prevents all of the phenomena described in Table 13.1 except for serialization anomalies. As mentioned above, this is specifically allowed by the standard, which only describes the minimum protections each isolation level must provide.
Repeatable Read 隔離級別只能看到事務開始前提交的資料；它永遠不會看到未提交的資料或併發事務在事務執行期間提交的更改。 （但是，查詢確實看到了在它自己的事務中執行的先前更新的影響，即使它們尚未提交。）這是比 SQL 標準對此隔離級別所要求的更強的保證，並且可以防止所有現象除序列化異常外，如表 13.1 所述。如上所述，這是標準明確允許的，它只描述了每個隔離級別必須提供的最低保護。

Sqlserver_Oracle_Mysql_Postgresql不同資料庫之隔離級別介紹

相關文章