[TOC] **可重復讀隔離級別** * 該級別**只能看到在事務開始之前被提交的數據**，看不到未提交的數據或者并行事務在本事務執行期間提交的修改 * 查詢能夠看見在它的事務中之前執行的更新，即使它們還沒有被提交 * UPDATE、 DELETE、 SELECT FOR UPDATE、 SELECT FOR SHARE對于這些命令，在查詢數據時的行為和 SELECT 完全一致。即只看到事務開始時已經提交的行。但在找到目標行時，這些記錄可能已經被其他并發的事務阻塞，譬如更新、刪除、加鎖。 * 開啟此級別的事務：BEGIN TRANSACTION ISOLATION LEVEL REPEATABLE READ; **與讀已提交隔離級別的區別：** * 讀已提交獲取的查詢命令開始時已提交的數據，一個事務中前后查詢到的數據可能不一致。 * 可重復讀獲取的是事務開始前已提交的數據，同一個事務中前后查詢獲取到的數據是一致的。注意是看到的是事務中第一個非事務控制語句看到快照，而不是事務中當前語句看到的快照。 # <span style="font-size:15px">**實例 1：驗證可重復讀隔離級別**</span> 1. session 1 和session 2開啟事務，session 2插入數據后提交，session 1查看數據  2. session 1 和session 2開啟事務，session 2插入數據后提交，session 1嘗試insert 和update session 2插入的數據  3 session 1開啟事務，本事務中插入數據后查看，結果可以看到數據，即使未提交  **結論：** * 可重復讀獲取的是事務開始前已提交的數據 * 在該隔離級別下，查詢看不到事務開始前未提交的數據，也看不到其他并發事務在該事務執行過程中提交的數據 * 在該隔離級別下，一個查詢可以看到該事務前面未提交的數據。 # <span style="font-size:15px">**實例2：阻塞事務回滾**</span>  **結論：** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;第一個阻塞事務回滾后，該事務的作用將被忽略，第二個事務可以繼續更新最初發現的行。 # <span style="font-size:15px">**實例3：阻塞事務提交**</span> 1. session 1和session 2同時更新相同數據  2. 事務A修改提交后，事務B加鎖  **結論：** * 在可重復讀的隔離級別中，第一個事務阻塞第二個事務，只有兩個事務作用的行有交叉才會發生阻塞。 * 第一個事務不論是修改提交或者是刪除提交，被阻塞的第二個事務都不能修改、刪除或者鎖住第一個事務所影響的行。否則將返回 ERROR: could not serialize access due to concurrent update。 * 第一個事務如果是僅僅鎖著然后提交釋放鎖(select for update/share)，則第二個被阻塞的事務可以進行作用最初發現的行。