PostgreSQL出現死鎖該如何解決

2022-05-30 14:01:31

什麼是資料庫死鎖

在作業系統領域當中，死鎖指的是兩個或者兩個以上的程序在執行的過程中，因為爭奪共同的存取資源而相互等待阻塞，最終導致程序繼無法續執行的一種阻塞現象。那麼在資料庫領域當中死鎖又是怎樣的表現形式呢？資料庫死鎖又會帶來怎樣的問題呢？

在理解資料庫死鎖之前，我們先來明確下資料庫的鎖到底是什麼？有過Java程式設計經驗的同學都知道，Java中的鎖是為了解決共用資料的並行存取安全問題，防止並行存取導致的共用資料出現錯亂。那麼在資料庫領域，資料庫中的鎖又是來幹什麼的呢？實際上在資料庫中所也是解決並行問題。假如在同一時刻，可能存在多個事務對同一張表的同一個欄位進行數位的加減操作，如果沒有任何的控制措施也同樣會導致各種各樣的資料一致性問題。因此資料庫的鎖實際上也是為了保證資料一致性的一種手段，對可能存在的並行操作進行控制。

下面以一個例子來進行說明，假設有這樣兩個事務，事務A中包含如下語句：

UPDATE user SET name = '小慕' where id = 1
UPDATE product SET price = price * 10 WHERE id = 2

事務B中包含如下語句：

UPDATE product SET price = price * 100 WHERE id = 2
UPDATE user SET name = '小楓' WHERE id = 1

如果這兩個事務並行執行，那麼他們可能存在如下的執行情況，當事務A執行的時候，首先執行了查詢語句：

UPDATE user SET name = '小慕' where id = 1

相當於事務A給id為1的資料行加上了排他鎖，但是事務並沒有執行完也就是說此時事務A持有user表的id為1的排他鎖，排他鎖的特性就是此時其他事務不能對資料進行刪除和修改，因此只有等待事務結束釋放鎖之後才能重新獲取。

此時事務B執行更新語句獲取了product表id為2的排他鎖，接著事務B開始執行user表的update語句，需要獲取user表的id為1的排他鎖。但是此時事務A並未提交，因此事務A持有表user的id為1的排他鎖，事務B只有乖乖阻塞等待事務A釋放鎖。而此時事務A執行update語句，需要獲取product的id為2的排他鎖，但是此時事務B持有該排他鎖，因此也需要等待事務B鎖釋放。

UPDATE product SET price = price * 10 WHERE id = 2

事務A在等待事務B結束釋放鎖，而事務B又在等待事務A釋放鎖，最終陷入了互相等待的情況也就是所謂的死鎖。

那麼資料庫出現死鎖又會導致什麼問題呢？資料庫死鎖會導致嚴重的效能問題，可能平臺因為資料庫死鎖而導致執行緩慢，嚴重影響使用者正常使用業務，因此如果出現資料庫死鎖情況需要及時發現以及解決。

定位死鎖

//先確定資料庫有沒有死鎖情況發生
select * from pg_stat_activity where datname = 'product_db';

//查詢可能鎖了的表的oid
select oid from pg_class where relname='product';

//查詢對應的pid
select pid from pg_locks where relation='oid'  //上面查詢出來的oid

//取消或者終止對應的程序破壞死鎖條件
select pg_cancel_backend(pid);
select pg_terminate_backend(pid)；

死鎖可能原因及解決辦法

以上分析了PostgreSQL出現死鎖後如何定位分析，那麼接下來就需要總結分析分析下PostgreSQL出現死鎖情況的原因以及一般的應對解決辦法。

1、索引使用不當導致的死鎖問題

索引使用存在問題的話會導致死鎖問題，假設在一個資料查詢的事務當中，進行資料檢索的時候沒辦法按照SQL中的where條件進行查詢，因此導致了全表掃描，那麼此時資料庫表的行級鎖會上升為表級鎖。如果此時有多個未能按照where條件進行資料查詢的事務存在，那麼就容易導致資料庫死鎖問題。也就是說在資料庫表資料量比較大的時候，對應進行資料查詢的表沒有建立索引或者說索引建立的不合理導致無法通過索引進行資料查詢，只能通過全表索引，這樣的場景下就容易產生死鎖。

如何避免：

在進行資料查詢的時候，對應的SQL語句不宜太過複雜，也就是說盡量避免多張表的關聯查詢。

2、不同事務之間的存取順序問題

當用戶A 存取資料庫表A時，此時對錶A加了共用鎖，然後又存取資料庫表B。而此時另一個使用者B 存取表B，對錶B加了共用鎖，然後試圖存取表A。但是使用者A由於使用者B已經鎖住表B，它必須等待使用者B釋放表B才能繼續，同樣使用者B要等使用者A釋放表A才能繼續，也就是說互相等待對方釋放資源，從而導致了死鎖的發生。

如何避免：

這種情況在實際專案中遇到的可能比較多，主要還是需要通過控制程式碼的執行邏輯，避免多表操作時同時鎖住多個資源。

避免死鎖的建議

（1）如果平臺中存在大事務，儘量將其拆分為小事務。因為大事務一般操作的資料庫表或者資料都比較多，因此造成死鎖或者阻塞的概率就會相對較大。

（2）為資料庫表設計合理的索引，儘量避免資料查詢時索引未覆蓋或者索引失效的情況，因為全表掃描會會導致給表中的資料行上鎖，大大增加了資料庫產生死鎖的概率。

（3）如果業務允許，我們可以嘗試將隔離級別調低，比如將隔離級別從RR調整為RC，可以避免掉很多因為gap鎖造成的死鎖。

（4）在我們自己的程式碼中，儘量以一致的順序獲取物件上的鎖，避免事務中SQL互動執行，從而降低死鎖發生的概率。

附：資料庫中常見的死鎖原因與解決方案

1. 事務之間對資源存取順序的交替

出現原因：

一個使用者A 存取表A（鎖住了表A），然後又存取表B；另一個使用者B 存取表B（鎖住了表B），然後企圖存取表A；這時使用者A由於使用者B已經鎖住表B，它必須等待使用者B釋放表B才能繼續，同樣使用者B要等使用者A釋放表A才能繼續，這就死鎖就產生了。

解決方法：

這種死鎖比較常見，是由於程式的BUG產生的，除了調整的程式的邏輯沒有其它的辦法。仔細分析程式的邏輯，對於資料庫的多表操作時，儘量按照相同的順序進行處理，儘量避免同時鎖定兩個資源，如操作A和B兩張表時，總是按先A後B的順序處理，必須同時鎖定兩個資源時，要保證在任何時刻都應該按照相同的順序來鎖定資源

2. 並行修改同一記錄

出現原因：主要是由於沒有一次性申請夠許可權的鎖導致的。

使用者A查詢一條紀錄，然後修改該條紀錄；這時使用者B修改該條紀錄，這時使用者A的事務裡鎖的性質由查詢的共用鎖企圖上升到獨佔鎖，而使用者B裡的獨佔鎖由於A有共用鎖存在所以必須等A釋放掉共用鎖，而A由於B的獨佔鎖而無法上升的獨佔鎖也就不可能釋放共用鎖，於是出現了死鎖。這種死鎖比較隱蔽，但在稍大點的專案中經常發生。

解決方法：

a. 樂觀鎖，實現寫-寫並行

b. 悲觀鎖：使用悲觀鎖進行控制。悲觀鎖大多數情況下依靠資料庫的鎖機制實現，如Oracle的Select … for update語句，以保證操作最大程度的獨佔性。但隨之而來的就是資料庫效能的大量開銷，特別是對長事務而言，這樣的開銷往往無法承受。

3. 索引不當導致的死鎖

出現原因：

如果在事務中執行了一條不滿足條件的語句，執行全表掃描，把行級鎖上升為表級鎖，多個這樣的事務執行後，就很容易產生死鎖和阻塞。類似的情況還有當表中的資料量非常龐大而索引建的過少或不合適的時候，使得經常發生全表掃描，最終應用系統會越來越慢，最終發生阻塞或死鎖。

另外一種情況是由於二級索引的存在，上鎖的順序不同導致的

解決方法：

SQL語句中不要使用太複雜的關聯多表的查詢；使用“執行計劃”對SQL語句進行分析，對於有全表掃描的SQL語句，建立相應的索引進行優化。