MySQL update 語句加鎖分析
InnoDB 儲存引擎的預設事務隔離級別是「可重複讀」，但是在這個隔離級別下，在多個事務併發的時候，會出現幻讀的問題。
所謂的幻讀是指在同一事務下，連續執行兩次同樣的查詢語句，第二次的查詢語句可能會返回之前不存在的行。
因此 InnoDB 儲存引擎自己實現了行鎖，通過 next-key 鎖（記錄鎖和間隙鎖的組合）來鎖住記錄本身和記錄之間的“間隙”，防止其他事務在這個記錄之間插入新的記錄，從而避免了幻讀現象。
當我們執行 update 語句時，實際上是會對記錄加獨佔鎖（X 鎖）的，如果其他事務對持有獨佔鎖的記錄進行修改時是會被阻塞的。
另外，這個鎖並不是執行完 update 語句就會釋放的，而是會等事務結束時才會釋放。
在 InnoDB 事務中，對記錄加鎖帶基本單位是 next-key 鎖，但是會因為一些條件會降級成間隙鎖，或者記錄鎖。加鎖的位置準確的說，鎖是加在索引上的而非行上。
比如，在 update 語句的 where 條件使用了唯一索引，那麼 next-key 鎖會降級成記錄鎖，也就是隻會給一行記錄加鎖。
這裡舉個例子，這裡有一張資料庫表，其中 id 為主鍵索引。
假設有兩個事務的執行順序如下：
可以看到，事務 A 的 update 語句中 where 是等值查詢，並且 id 是唯一索引，所以只會對 id = 1 這條記錄加鎖，因此，事務 B 的更新操作並不會阻塞。
但是，在 update 語句的 where 條件沒有使用索引，就會全表掃描，於是就會對所有記錄加上 next-key 鎖（記錄鎖 + 間隙鎖），相當於把整個表鎖住了。
假設有兩個事務的執行順序如下：
可以看到，這次事務 B 的 update 語句被阻塞了。
這是因為事務 A的 update 語句中 where 條件沒有索引列，所有記錄都會被加鎖，也就是這條 update 語句產生了 4 個記錄鎖和 5 個間隙鎖，相當於鎖住了全表。
因此，當在資料量非常大的資料庫表執行 update 語句時，如果沒有使用索引，就會給全表的加上 next-key 鎖， 那麼鎖就會持續很長一段時間，直到事務結束。
而這期間除了 select ... from 語句，其他語句都會被鎖住不能執行，業務會因此停滯，接下來等著你的，就是老闆的捱罵。
那 update 語句的 where 帶上索引就能避免全表記錄加鎖了嗎？並不是。
關鍵還得看這條語句在執行過程中，優化器最終選擇的是索引掃描，還是全表掃描，如果走了全表掃描，就會對全表的記錄加鎖了。
又該如何避免這種事故的發生？
我們可以將 MySQL 裡的 sql_safe_updates 引數設定為 1，開啟安全更新模式。
官方的解釋：
If set to 1, MySQL aborts UPDATE or DELETE statements that do not use a key in the WHERE clause or a LIMIT clause. (Specifically, UPDATE statements must have a WHERE clause that uses a key or a LIMIT clause, or both. DELETE statements must have both.) This makes it possible to catch UPDATE or DELETE statements where keys are not used properly and that would probably change or delete a large number of rows. The default value is 0.
大致的意思是，當 sql_safe_updates 設定為 1 時，update 語句必須滿足如下條件之一才能執行成功：
-
使用 where，並且 where 條件中必須有索引列。
-
使用 limit。
-
同時使用 where 和 limit，此時 where 條件中可以沒有索引列。
delete 語句必須滿足如下條件之一才能執行成功：
-
使用 where，並且 where 條件中必須有索引列。
-
同時使用 where 和 limit，此時 where 條件中可以沒有索引列。
如果 where 條件帶上了索引列，但是優化器最終掃描選擇的是全表，而不是索引的話，我們可以使用 force index([index_name])可以告訴優化器使用哪個索引，以此避免有機率鎖全錶帶來的隱患。
總結
不要小看一條 update 語句，在生產機上使用不當可能會導致業務停滯，甚至崩潰。
當我們要執行 update 語句的時候，確保 where 條件中帶上了索引列，並且在測試機確認該語句是否走的是索引掃描，防止因為掃描全表，而對錶中的所有記錄加上鎖。
我們可以開啟 MySQL 裡的 sql_safe_updates 引數，這樣可以預防 update 操作時 where 條件沒有帶上索引列。
如果發現即使在 where 條件中帶上了列索引列，優化器走的還是全標掃描，這時我們就要使用 force index([index_name])可以告訴優化器使用哪個索引。