數據庫的兩種鎖類型:數據庫
排它鎖:數據被加上排它鎖的時候,其餘事務不能進行查詢和修改併發
共享鎖: 數據被加上共享鎖的時候,其餘事務能夠查詢可是不能修改性能
發生死鎖的緣由:優化
一、事務之間對資源訪問順序的交替spa
假設有用戶A和用戶B,用戶A訪問了A表(鎖住了A表)以後又去訪問B表,這時用戶B訪問了B表(鎖住了B表)以後又去訪問A表。索引
這時候因爲用戶A訪問B表已經被用戶B鎖住了,必須等待B釋放鎖。同時用戶B要訪問A表一樣也被用戶A鎖住了,這時候就會發生互相等待,就發生了死鎖。事務
解決方法:資源
調整程序邏輯順序,儘可能按相同的順序處理。io
二、併發先查詢後修改同一記錄程序
用戶A去查詢A表(會獲取共享鎖)這時候又去修改某一條數據就會企圖升級爲排它鎖,這時候用戶B也查詢A表(一樣也獲取了共享鎖)這時候用戶B也去修改數據也會企圖升級爲排它鎖,就會等待用戶A釋放共享鎖,B一樣在等待A釋放共享鎖
解決方法:
一、樂觀鎖
用version字段進行控制,查詢出來的version版本若是和修改時候的version版本不一致的話就修改不成功,修改完成version版本+1
二、悲觀鎖
依靠數據庫的鎖機制實現,數據庫性能的大量開銷
三、全表掃描
若是執行了一個不知足條件的查詢語句,由行級鎖上升爲表級鎖,多個這樣的事務執行後,就很容易產生死鎖和阻塞。相似的狀況還有當表中的數據量很是龐大而索引建的過少或不合適的時候,使得常常發生全表掃描,最終應用系統會愈來愈慢,最終發生阻塞或死鎖。
解決方法:
SQL語句中不要使用太複雜的關聯多表的查詢;使用「執行計劃」對SQL語句進行分析,對於有全表掃描的SQL語句,創建相應的索引進行優化。