一：分類 1.樂觀鎖：用數據版本記錄機制實現。為數據增加一個版本表示，一般是資料庫增加一個version欄位。讀取數據時，把version欄位一起獨處，每更新一次，version+1.提交時，提交版本必須大於當前版本才能執行更新。 2.悲觀鎖，在操作數據時，認為此操作會出現數據衝突，所以在進行每次操 ...
一：分類
1.樂觀鎖：用數據版本記錄機制實現。
為數據增加一個版本表示，一般是資料庫增加一個version欄位。讀取數據時，把version欄位一起獨處，每更新一次，version+1.
提交時，提交版本必須大於當前版本才能執行更新。
2.悲觀鎖，在操作數據時，認為此操作會出現數據衝突，所以在進行每次操作時都要通過獲取鎖才能進行對相同數據的操作。
3.悲觀鎖設計到的另外兩個鎖概念：共用鎖和排他鎖都是悲觀鎖的一種實現。
4.共用鎖（讀鎖），讀取操作創建的額鎖。其他用戶可以併發讀取數據，但不能對其進行修改，直到已釋放所有共用鎖
如果事務T對數據a加共用鎖，則其他事務不能再加排它鎖。獲得共用鎖的事務只能讀數據
5.排它鎖（寫鎖），加鎖之後，可以讀也可以寫，其他時候不能再加鎖。
6.行鎖，給某一行，也就是某一條記錄加鎖。基於索引的，所以如果sql語句用不到索引也就用不到行鎖，只會用到表鎖。
7.表鎖。innodb引擎在用不到索引也就是用不到行鎖的時候，行鎖會變成表鎖。
8.死鎖，兩個或兩個以上進程，因爭奪資源而造成一種互相等待的現象。
二、解決方法
1.查詢是否鎖表
show OPEN TABLES where In_use > 0;
2.查詢所有進程
show processlist
3.殺死進程
kill id
或者先查看事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
查看鎖定的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
查看當前等鎖的事務
SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
三、產生和避免
如果系統資源充足，進程的資源請求都能夠得到滿足，死鎖出現的可能性就很低，否則就會因爭奪有限的資源而陷入死鎖。其次，進程運行推進順序與速度不同，也可能產生死鎖。
產生死鎖的四個必要條件：
（1） 互斥條件：一個資源每次只能被一個進程使用。
（2） 請求與保持條件：一個進程因請求資源而阻塞時，對已獲得的資源保持不放。
（3） 不剝奪條件:進程已獲得的資源，在末使用完之前，不能強行剝奪。
（4） 迴圈等待條件:若幹進程之間形成一種頭尾相接的迴圈等待資源關係。
雖然不能完全避免死鎖，但可以使死鎖的數量減至最少。將死鎖減至最少可以增加事務的吞吐量並減少系統開銷，因為只有很少的事務回滾，而回滾會取消事務執行的所有工作。由於死鎖時回滾而由應用程式重新提交。
下列方法有助於最大限度地降低死鎖：
（1）按同一順序訪問對象。
（2）避免事務中的用戶交互。
（3）保持事務簡短併在一個批處理中。
（4）使用低隔離級別。
（5）使用綁定連接。
