[TOC] **讀已提交隔離級別** * 讀已提交是PostgreSQL中的默認隔離級別 * 一個查詢（沒有`FOR UPDATE/SHARE`子句），只能看到查詢開始之前已經被提交的數據， 而無法看到未提交的數據或在查詢執行期間其它事務提交的數據 * `SELECT`查詢看到的是一個在查詢開始運行前該數據庫的一個快照 * `SELECT`可以看見在它自身事務中之前執行的更新的效果，即使它們還沒有被提交 * 在同一個事務的兩個查詢可能查詢到的數據并不相同。可能發生不可重復讀。因為其它事務可能會在第一個`SELECT`開始和第二個`SELECT`開始之間提交 * UPDATE、DELETE、SELECT FOR UPDATE 和 SELECT FOR SHARE命令，在查詢數據時和 SELECT 的行為一致。都是查詢命令執行前已經提交的數據。這些命令在查詢數據的時候，可能會被其他并發事務阻塞(如：更新操作，刪除操作，或者加鎖)。 阻塞事務可能會回滾或者提交。在這種情況下， 即將進行的更新將等待第一個更新事務提交或者回滾（如果它還在進行中）。 如果第一個更新事務回滾，那么它的作用將被忽略并且第二個事務可以繼續更新最初發現的行。 如果第一個更新事務提交，若該行被第一個更新者刪除，則第二個更新事務將忽略該行，否則第二個更新者將試圖在該行的已被更新的版本上應用它的操作 <br> # <span style="font-size:15px">**實例 1：驗證讀已提交隔離級別**</span>  **結論：** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;查詢只能看到已提交的數據，未提交的數據或者查詢過程中其他事務提交的數據無法看到 <br> # <span style="font-size:15px">**實例2：驗證可能發生不可重復讀的場景**</span>  **結論：** &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;在讀已提交的隔離模式下，查詢操作獲取的結果是查詢操作前已經提交的數據。因此，在同一個事務中的兩次select 查詢的數據可能并不相同，是可能發生不可重復讀的。 <br> # <span style="font-size:15px">**實例3：阻塞事務回滾**</span> 1. 開啟兩個會話，同時開啟事務并更新相同數據  2. session 1 在事務中執行回滾操作  3. 開啟兩個會話，同時開啟事務，并更新不同的數據  **結論：** * 第一個事務回滾，那么它的作用將被忽略，第二個事務將繼續執行它的操作 * 兩個事務更新不同的數據，不會被阻塞 <br> # <span style="font-size:15px">**實例4：阻塞事務提交**</span> 1. 驗證刪除提交 ① session 1和session 2同時開啟事務，session 1刪除數據，session 2更新數據  ② session 1提交事務，session 2 的語句將不生效  **結論：** * 如果第一個事務進行刪除提交，那么第二個事務將忽略該行。 * 如果第一個事務影響的數據和第二個事務影響的數據不同，則不會阻塞。 2. 驗證更新提交 ① 場景1：第一個事務更新后數據依然滿足事務2的查詢條件   ① 場景1：第一個事務更新后數據不滿足事務2的查詢條件  **結論：** * 第一個事務提交后，如果修改后的記錄仍然滿足第二個事務的條件(where 子句將會重新計算來看該行被更新后的版本是否滿足搜索條件)，則會修改被影響。 否則將不會受影響。 * 對于原來不滿足事務B的記錄，經過事務A修改滿足事務B后提交的，也不會被事務B影響。事務B只作用最初發現的記錄