MySQL 行鎖 表鎖機制
MySQL 表鎖和行鎖機制
行鎖變表鎖，是福還是坑？如果你不清楚MySQL加鎖的原理，你會被它整的很慘！不知坑在何方？沒事，我來給你們標記幾個坑。遇到了可別亂踩。通過本章內容，帶你學習MySQL的行鎖，表鎖，兩種鎖的優缺點，行鎖變表鎖的原因，以及開發中需要註意的事項。還在等啥？經驗等你來拿！
MySQL的存儲引擎是從MyISAM到InnoDB，鎖從表鎖到行鎖。後者的出現從某種程度上是彌補前者的不足。比如：MyISAM不支持事務，InnoDB支持事務。表鎖雖然開銷小，鎖表快，但高並發下性能低。行鎖雖然開銷大，鎖表慢，但高並發下相比之下性能更高。事務和行鎖都是在確保數據準確的基礎上提高並發的處理能力。本章重點介紹InnoDB的行鎖。
案例分析
目前，MySQL常用的存儲引擎是InnoDB，相對於MyISAM而言。InnoDB更適合高並發場景，同時也支持事務處理。我們通過下面這個案例(坑)，來了解行鎖和表鎖。
業務：因為訂單重復導入，需要用腳本將訂單狀態為"待客服確認"且平臺是"xxx"的數據批量修改為"已關閉"。
說明：避免直接修改訂單表造成數據異常。這裏用innodb_lock 表演示InnoDB的行鎖。表中有三個字段：id，k(key值)，v(value值)。
步驟：
第一步：連接數據庫，這裏為了方便區分命名為Transaction-A，設置autocommit為零，表示需手動提交事務。
第三步：新增一個連接，命名為Transaction-B，能正常修改id為2的數據。再執行修改id為1的數據命令時，卻發現該命令一直處理阻塞等待中。
第四步：Transaction-A，執行commit命令。Transaction-B，修改id為1的命令自動執行，等待37.51秒。
總結：多個事務操作同一行數據時，後來的事務處於阻塞等待狀態。這樣可以避免了臟讀等數據一致性的問題。後來的事務可以操作其他行數據，解決了表鎖高並發性能低的問題。
# Transaction-A
mysql> set autocommit = 0 有了上面的模擬操作，結果和理論又驚奇的一致，似乎可以放心大膽的實戰。。。。。。但現實真的很殘酷。
現實：當執行批量修改數據腳本的時候，行鎖升級為表鎖。其他對訂單的操作都處於等待中，，，
原因：InnoDB只有在通過索引條件檢索數據時使用行級鎖，否則使用表鎖！而模擬操作正是通過id去作為檢索條件，而id又是MySQL自動創建的唯一索引，所以才忽略了行鎖變表鎖的情況。
步驟：
第一步：還原問題，Transaction-A，通過k=1更新v。Transaction-B，通過k=2更新v，命令處於阻塞等待狀態。
第二步：處理問題，給需要作為查詢條件的字段添加索引。用完後可以刪掉。
總結：InnoDB的行鎖是針對索引加的鎖，不是針對記錄加的鎖。並且該索引不能失效，否則都會從行鎖升級為表鎖。索引失效的原因在上一章節中已經介紹：http://www.cnblogs.com/itdragon/p/8146439.html
Transaction-A
mysql> update innodb_lock set v='1002' where k=1;
mysql> commit;
mysql> create index idx_k on innodb_lock(k);
Transaction-B
mysql> update innodb_lock set v='2002' where k=2;
Query OK, 1 row affected (19.82 sec)從上面的案例看出，行鎖變表鎖似乎是一個坑，可MySQL沒有這麽無聊給你挖坑。這是因為MySQL有自己的執行計劃。
當你需要更新一張較大表的大部分甚至全表的數據時。而你又傻乎乎地用索引作為檢索條件。一不小心開啟了行鎖(沒毛病啊！保證數據的一致性！)。可MySQL卻認為大量對一張表使用行鎖，會導致事務執行效率低，從而可能造成其他事務長時間鎖等待和更多的鎖沖突問題，性能嚴重下降。所以MySQL會將行鎖升級為表鎖，即實際上並沒有使用索引。
我們仔細想想也能理解，既然整張表的大部分數據都要更新數據，一行一行地加鎖效率則更低。其實我們可以通過explain命令查看MySQL的執行計劃，你會發現key為null。表明MySQL實際上並沒有使用索引，行鎖升級為表鎖也和上面的結論一致。
本章重點介紹InnoDB的行鎖及其相關的事務知識。如果想了解MySQL的執行計劃，請看上一章節。
行鎖
行鎖的劣勢：開銷大；加鎖慢；會出現死鎖
行鎖的優勢：鎖的粒度小，發生鎖沖突的概率低；處理並發的能力強
加鎖的方式：自動加鎖。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數據集加排他鎖；對於普通SELECT語句，InnoDB不會加任何鎖；當然我們也可以顯示的加鎖：
共享鎖：select * from tableName where ... + lock in share more
排他鎖：select * from tableName where ... + for update
InnoDB和MyISAM的最大不同點有兩個：一，InnoDB支持事務(transaction)；二，默認采用行級鎖。加鎖可以保證事務的一致性，可謂是有人(鎖)的地方，就有江湖(事務)；我們先簡單了解一下事務知識。
MySQL 事務屬性
事務是由一組SQL語句組成的邏輯處理單元，事務具有ACID屬性。
原子性（Atomicity）：事務是一個原子操作單元。在當時原子是不可分割的最小元素，其對數據的修改，要麽全部成功，要麽全部都不成功。
一致性（Consistent）：事務開始到結束的時間段內，數據都必須保持一致狀態。
隔離性（Isolation）：數據庫系統提供一定的隔離機制，保證事務在不受外部並發操作影響的"獨立"環境執行。
持久性（Durable）：事務完成後，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。
事務常見問題
更新丟失（Lost Update）
原因：當多個事務選擇同一行操作，並且都是基於最初選定的值，由於每個事務都不知道其他事務的存在，就會發生更新覆蓋的問題。類比github提交沖突。
臟讀（Dirty Reads）
原因：事務A讀取了事務B已經修改但尚未提交的數據。若事務B回滾數據，事務A的數據存在不一致性的問題。
不可重復讀（Non-Repeatable Reads）
原因：事務A第一次讀取最初數據，第二次讀取事務B已經提交的修改或刪除數據。導致兩次讀取數據不一致。不符合事務的隔離性。
幻讀（Phantom Reads）
原因：事務A根據相同條件第二次查詢到事務B提交的新增數據，兩次數據結果集不一致。不符合事務的隔離性。
幻讀和臟讀有點類似
臟讀是事務B裏面修改了數據，
幻讀是事務B裏面新增了數據。
事務的隔離級別
數據庫的事務隔離越嚴格，並發副作用越小，但付出的代價也就越大。這是因為事務隔離實質上是將事務在一定程度上"串行"進行，這顯然與"並發"是矛盾的。根據自己的業務邏輯，權衡能接受的最大副作用。從而平衡了"隔離" 和 "並發"的問題。MySQL默認隔離級別是可重復讀。
臟讀，不可重復讀，幻讀，其實都是數據庫讀一致性問題，必須由數據庫提供一定的事務隔離機制來解決。
+------------------------------+---------------------+--------------+--------------+--------------+
| 隔離級別 | 讀數據一致性 | 臟讀 | 不可重復 讀 | 幻讀 |
+------------------------------+---------------------+--------------+--------------+--------------+
| 未提交讀(Read uncommitted) | 最低級別 | 是 | 是 | 是 |
+------------------------------+---------------------+--------------+--------------+--------------+
| 已提交讀(Read committed) | 語句級 | 否 | 是 | 是 |
+------------------------------+---------------------+--------------+--------------+--------------+
| 可重復讀(Repeatable read) | 事務級 | 否 | 否 | 是 |
+------------------------------+---------------------+--------------+--------------+--------------+
| 可序列化(Serializable) | 最高級別，事務級 | 否 | 否 | 否 |
+------------------------------+---------------------+--------------+--------------+--------------+查看當前數據庫的事務隔離級別：show variables like ‘tx_isolation‘;
mysql> show variables like 'tx_isolation';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| tx_isolation | REPEATABLE-READ |
+---------------+-----------------+間隙鎖
當我們用範圍條件檢索數據，並請求共享或排他鎖時，InnoDB會給符合條件的已有數據記錄的索引項加鎖；對於鍵值在條件範圍內但並不存在的記錄，叫做"間隙(GAP)"。InnoDB也會對這個"間隙"加鎖，這種鎖機制就是所謂的間隙鎖(Next-Key鎖)。
Transaction-A
mysql> update innodb_lock set k=66 where id >=6;
Query OK, 1 row affected (0.63 sec)
mysql> commit;
Transaction-B
mysql> insert into innodb_lock (id,k,v) values(7,'7','7000');
Query OK, 1 row affected (18.99 sec)危害(坑)：若執行的條件是範圍過大，則InnoDB會將整個範圍內所有的索引鍵值全部鎖定，很容易對性能造成影響。
排他鎖
排他鎖，也稱寫鎖，獨占鎖，當前寫操作沒有完成前，它會阻斷其他寫鎖和讀鎖。
# Transaction_A
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 for update;
+----+------+------+
| id | k | v |
+----+------+------+
| 4 | 4 | 4000 |
+----+------+------+
1 row in set (0.00 sec)
mysql> update innodb_lock set v='4001' where id=4;
Query OK, 1 row affected (0.00 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> commit;
Query OK, 0 rows affected (0.04 sec)# Transaction_B
mysql> select * from innodb_lock where id=4 for update;
+----+------+------+
| id | k | v |
+----+------+------+
| 4 | 4 | 4001 |
+----+------+------+
1 row in set (9.53 sec)共享鎖
共享鎖，也稱讀鎖，多用於判斷數據是否存在，多個讀操作可以同時進行而不會互相影響。當如果事務對讀鎖進行修改操作，很可能會造成死鎖。如下圖所示。
# Transaction_A
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 lock in share mode;
+----+------+------+
| id | k | v |
+----+------+------+
| 4 | 4 | 4001 |
+----+------+------+
1 row in set (0.00 sec)
mysql> update innodb_lock set v='4002' where id=4;
Query OK, 1 row affected (31.29 sec)
Rows matched: 1 Changed: 1 Warnings: 0# Transaction_B
mysql> set autocommit=0;
mysql> select * from innodb_lock where id=4 lock in share mode;
+----+------+------+
| id | k | v |
+----+------+------+
| 4 | 4 | 4001 |
+----+------+------+
1 row in set (0.00 sec)
mysql> update innodb_lock set v='4002' where id=4;
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction分析行鎖定
通過檢查InnoDB_row_lock 狀態變量分析系統上的行鎖的爭奪情況 show status like ‘innodb_row_lock%‘
mysql> show status like 'innodb_row_lock%';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| Innodb_row_lock_current_waits | 0 |
| Innodb_row_lock_time | 0 |
| Innodb_row_lock_time_avg | 0 |
| Innodb_row_lock_time_max | 0 |
| Innodb_row_lock_waits | 0 |
+-------------------------------+-------+innodb_row_lock_current_waits: 當前正在等待鎖定的數量
innodb_row_lock_time: 從系統啟動到現在鎖定總時間長度；非常重要的參數，
innodb_row_lock_time_avg: 每次等待所花平均時間；非常重要的參數，
innodb_row_lock_time_max: 從系統啟動到現在等待最常的一次所花的時間；
innodb_row_lock_waits: 系統啟動後到現在總共等待的次數；非常重要的參數。直接決定優化的方向和策略。
行鎖優化
1 盡可能讓所有數據檢索都通過索引來完成，避免無索引行或索引失效導致行鎖升級為表鎖。
2 盡可能避免間隙鎖帶來的性能下降，減少或使用合理的檢索範圍。
3 盡可能減少事務的粒度，比如控制事務大小，而從減少鎖定資源量和時間長度，從而減少鎖的競爭等，提供性能。
4 盡可能低級別事務隔離，隔離級別越高，並發的處理能力越低。
表鎖
表鎖的優勢：開銷小；加鎖快；無死鎖
表鎖的劣勢：鎖粒度大，發生鎖沖突的概率高，並發處理能力低
加鎖的方式：自動加鎖。查詢操作（SELECT），會自動給涉及的所有表加讀鎖，更新操作（UPDATE、DELETE、INSERT），會自動給涉及的表加寫鎖。也可以顯示加鎖：
共享讀鎖：lock table tableName read;
獨占寫鎖：lock table tableName write;
批量解鎖：unlock tables;
共享讀鎖
對MyISAM表的讀操作（加讀鎖），不會阻塞其他進程對同一表的讀操作，但會阻塞對同一表的寫操作。只有當讀鎖釋放後，才能執行其他進程的寫操作。在鎖釋放前不能取其他表。
Transaction-A
mysql> lock table myisam_lock read;
Query OK, 0 rows affected (0.00 sec)
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> select * from innodb_lock;
ERROR 1100 (HY000): Table 'innodb_lock' was not locked with LOCK TABLES
mysql> update myisam_lock set v='1001' where k='1';
ERROR 1099 (HY000): Table 'myisam_lock' was locked with a READ lock and can't be updated
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)Transaction-B
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> select * from innodb_lock;
8 rows in set (0.01 sec)
mysql> update myisam_lock set v='1001' where k='1';
Query OK, 1 row affected (18.67 sec)獨占寫鎖
對MyISAM表的寫操作（加寫鎖），會阻塞其他進程對同一表的讀和寫操作，只有當寫鎖釋放後，才會執行其他進程的讀寫操作。在鎖釋放前不能寫其他表。
Transaction-A
mysql> set autocommit=0;
Query OK, 0 rows affected (0.05 sec)
mysql> lock table myisam_lock write;
Query OK, 0 rows affected (0.03 sec)
mysql> update myisam_lock set v='2001' where k='2';
Query OK, 1 row affected (0.00 sec)
mysql> select * from myisam_lock;
9 rows in set (0.00 sec)
mysql> update innodb_lock set v='1001' where k='1';
ERROR 1100 (HY000): Table 'innodb_lock' was not locked with LOCK TABLES
mysql> unlock tables;
Query OK, 0 rows affected (0.00 sec)Transaction-B
mysql> select * from myisam_lock;
9 rows in set (42.83 sec)總結：表鎖，讀鎖會阻塞寫，不會阻塞讀。而寫鎖則會把讀寫都阻塞。
查看加鎖情況
show open tables; 1表示加鎖，0表示未加鎖。
mysql> show open tables where in_use > 0;
+----------+-------------+--------+-------------+
| Database | Table | In_use | Name_locked |
+----------+-------------+--------+-------------+
| lock | myisam_lock | 1 | 0 |
+----------+-------------+--------+-------------+分析表鎖定
可以通過檢查table_locks_waited 和 table_locks_immediate 狀態變量分析系統上的表鎖定：show status like ‘table_locks%‘
mysql> show status like 'table_locks%';
+----------------------------+-------+
| Variable_name | Value |
+----------------------------+-------+
| Table_locks_immediate | 104 |
| Table_locks_waited | 0 |
+----------------------------+-------+table_locks_immediate: 表示立即釋放表鎖數。
table_locks_waited: 表示需要等待的表鎖數。此值越高則說明存在著越嚴重的表級鎖爭用情況。
此外，MyISAM的讀寫鎖調度是寫優先，這也是MyISAM不適合做寫為主表的存儲引擎。因為寫鎖後，其他線程不能做任何操作，大量的更新會使查詢很難得到鎖，從而造成永久阻塞。
什麽場景下用表鎖
InnoDB默認采用行鎖，在未使用索引字段查詢時升級為表鎖。MySQL這樣設計並不是給你挖坑。它有自己的設計目的。
即便你在條件中使用了索引字段，MySQL會根據自身的執行計劃，考慮是否使用索引(所以explain命令中會有possible_key 和 key)。如果MySQL認為全表掃描效率更高，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖沖突時，別忘了檢查SQL的執行計劃，以確認是否真正使用了索引。
第一種情況：全表更新。事務需要更新大部分或全部數據，且表又比較大。若使用行鎖，會導致事務執行效率低，從而可能造成其他事務長時間鎖等待和更多的鎖沖突。
第二種情況：多表查詢。事務涉及多個表，比較復雜的關聯查詢，很可能引起死鎖，造成大量事務回滾。這種情況若能一次性鎖定事務涉及的表，從而可以避免死鎖、減少數據庫因事務回滾帶來的開銷。
頁鎖
開銷和加鎖時間介於表鎖和行鎖之間；會出現死鎖；鎖定粒度介於表鎖和行鎖之間，並發處理能力一般。只需了解一下。
總結
1 InnoDB 支持表鎖和行鎖，使用索引作為檢索條件修改數據時采用行鎖，否則采用表鎖。
2 InnoDB 自動給修改操作加鎖，給查詢操作不自動加鎖
3 行鎖可能因為未使用索引而升級為表鎖，所以除了檢查索引是否創建的同時，也需要通過explain執行計劃查詢索引是否被實際使用。
4 行鎖相對於表鎖來說，優勢在於高並發場景下表現更突出，畢竟鎖的粒度小。
5 當表的大部分數據需要被修改，或者是多表復雜關聯查詢時，建議使用表鎖優於行鎖。
6 為了保證數據的一致完整性，任何一個數據庫都存在鎖定機制。鎖定機制的優劣直接影響到一個數據庫的並發處理能力和性能。
到這裏，Mysql的表鎖和行鎖機制就介紹完了，若你不清楚InnoDB的行鎖會升級為表鎖，那以後會吃大虧的。若有打什麽不對的地方請指正。若覺得文章不錯，麻煩點個贊！來都來了，留下你的痕跡吧！
MySQL 行鎖 表鎖機制