sqlserver leftjoin出現重複資料_資料庫存資料時，邏輯上防重了為啥還會出現重複記錄？...

在很多異常情況下，比如高并發、網絡糟糕的時候，資料庫裡偶爾會出現重複的記錄。

假如現在有一張書籍表，結構類似這樣

在異常情況下，可能會出現下面這樣的記錄

但是，想了想，自己在處理相關資料的時候也加了判重的相關邏輯，比如，新增時當圖書 name 相同時，會提示圖書重複而傳回。

初次遇到這個情況的時候，感覺有點摸不着頭腦，後面想了想，還是理清了，其實這和資料庫的事務隔離級别有一定關系。

先簡單說下資料庫事務的 4 個隔離級别，然後重制下上述問題，最後說說解決辦法。

1 資料庫事務的 4 個隔離級别

1.1 未送出讀

顧名思義，當事務隔離級别處于這個設定的時候，不同僚務能讀取其它事務中未送出的資料。

便于說明，我開了兩個用戶端(A 以及 B)，并設定各自的隔離級别為未送出讀。(并沒有全局設定)

設定隔離級别指令

好了，開始。

Client A

當 A 中的事務沒有關閉的時候，我們去 B 中看下資料

Client B

B 中可以讀取 A 未送出的資料，所謂未送出讀就是這樣。

最後，記得把各個事務送出。

Client A & Client B

1.2 送出讀

不能事務可以讀取其它事務中已經送出的資料。

篇幅問題，這裡我就不貼出設定隔離級别的語句，測試某個隔離級别的時候，預設已經設定好該級别。

Client A

A 沒送出，在 B 裡面去看下資料

Client B

和預期一樣，A 中未送出的資料在 B 中看不到。

A 中送出事務

Client A

在 B 中看下

Client B

B 中能看到 A 中送出的資料。

1.3 可重複讀

細心的朋友可能會發現一個問題，那就是在 B 中的同一個事務讀同一個表，得到的結果卻不一緻，開始隻有 1 條，後面有 2 條，而如果沒有這個問題的話，也就是可重複讀了。

我們來驗證下

Client A

Client B

Client A

Client B

和預期一緻。B 中事務沒有受到 A 中事務的送出影響，讀取的資料和事務剛開始的時候一緻，books 中都隻有一條資料，這就是可重複讀。

當然，B 在自己的事務中做修改，肯定是可見的。

Client B

1.4 串行化

這是隔離級别最嚴格的一級，在該級别中，不同僚務中的讀寫會互相阻塞。

Client A

當 A 未送出的時候在 B 中對同一個表進行寫

Client B

由于不同僚務中的讀寫互相阻塞，是以出現了上面逾時的情況。

如果 A 中送出事務

Client A

那麼在 B 中就能正常寫了

Client B

同理，在 A 中開啟事務并向 books 中插入一條記錄後不送出，B 中開啟事務并對該表進行讀操作，也會逾時。當 A 中的事務送出後，B 中對 books 的讀操作就沒有問題了。

2 重制問題

由于 MySQL 的 Innodb 的預設事務隔離級别為可重複讀，也就導緻了判重邏輯可能會出現問題，我們來重制一下。

現在，資料庫的資料是這樣的

後端邏輯類似這樣的

當兩個使用者輸入書名「人類簡史」并送出後，同時有兩個線程執行這段邏輯，也就相當于上面兩個用戶端同時開啟了事務，我們以這兩個用戶端來說明問題

Client A

A 中檢測圖書不存在，然後插入，但是由于「其它操作」由于網絡或者其它原因太費時間，導緻事務送出延遲。

這時在 B 中執行類似操作

Client B

由于事務隔離級别是可重複讀的，B 中無法讀取 A 中未送出的資料，是以判重邏輯順利通過，也插入了同一本書。(也就是說隔離級别在送出讀及以上都有可能出現這個問題)

最後 A 和 B 都送出後

Client A & Clinet B

就出現了重複記錄了

3 怎麼解決

3.1 資料庫層面

從底層進行限制，對 name 添加唯一索引後，插入重複記錄會報錯，簡單粗暴的解決了這個問題。

3.2 代碼層面

加唯一索引能解決，但是總覺得代碼不夠完整，其實在代碼層面也可以解決這個問題。

如果我們在接收請求的時候如果碰到關鍵參數相同的請求，我們可以直接拒絕，傳回類似「操作進行中」的響應，這樣也就從源頭上解決了這個問題。

實作上面的思路也很簡單，借助 redis 的 setnx 即可。

如果類似場景比較多，可以考慮把 redis 的操作封裝成一個裝飾器，讓代碼能複用起來，這裡不再贅述。

4 小結

由于資料庫隔離級别的原因，一些資料就算是邏輯上進行防重了，也有可能出現重複記錄。解決這個問題，可以在資料庫層面加唯一索引解決，也可以在代碼層面進行解決。

原文部落格：www.kevinbai.com

關注「小小後端」公衆号，更多幹貨等着你喔！