mysql 併發控制

1、多個執行緒同時修改資料，存在資料不一致的情況，也就是併發控制的問題。

2、mysql提供讀鎖和寫鎖，讀鎖之上可以再加讀鎖，不能加寫鎖，而寫鎖之上不能加任何鎖。也就是說，讀鎖是共享的，寫鎖是排他的。

3、鎖粒度，為了更好的併發控制，鎖的粒度應該盡可能小，也就是只鎖定修改的資料。但是，鎖本身也有一定的開銷，包括獲取鎖，檢查鎖是否釋放，釋放鎖，這些操作也耗費一定的資源。鎖的粒度小，在併發控制的時候，也就意味著需要更多的鎖，鎖的總開銷也就越大。

4、根據鎖的粒度，分為表鎖和行鎖，mysql本身使用表鎖來實現不同的目的，比如alter table，這個時候會忽略儲存引擎的鎖機制。儲存引擎支援表鎖和行鎖，不同儲存引擎的實現不同。

5、特別注意：mysql支援不同的事務隔離級別，隔離級別越高，鎖的粒度越大，也就是鎖的內容越多。比如：

考慮下面的情況，a，b客戶端的事務隔離級別都是read-uncommitted, 鎖的粒度是行鎖。

步驟一、a執行start transaction，修改一條記錄

步驟二、b執行start transaction，修改另一條記錄

二者是不阻塞的，證明read-uncommitted 是行鎖。同理，可以證明read-committed是行鎖，repeatable-read和serializable是表鎖。

注意：加什麼鎖，鎖多大範圍，和很多因素有關，包括是否有索引，執行的操作等。比如上面的情況，a、b都是repeatable-read，a進行select，b進行update不阻塞。但是a進行update，b進行update就會阻塞。

6、死鎖，mysql在事務中，innodb會根據事務隔離級別自動鎖定，而釋放實在事務commit或者rollback的時候才釋放。這就會存在死鎖的情況，考慮下面的情況：

a，b客戶端的事務隔離級別都是read-uncommitted, 鎖的粒度是行鎖。

步驟一、a執行start transaction，修改記錄1

步驟二、b執行start transaction，修改記錄2

步驟三、a修改記錄2

步驟四、b修改記錄1

出現死鎖，不過mysql功能很強大，可以檢測出這種死鎖，b修改記錄1的時候報錯 error 1213 (40001): deadlock found when trying to get lock; try restarting trans

action