MySQL的鎖機制比較簡單，其最顯著的特點是不同的存儲引擎支持不同的鎖機制。比如，MyISAM和MEMORY存儲引擎
采用的是表級鎖；BDB存儲引擎采用的是頁面鎖，但也支持表級鎖；InnoDB存儲引擎既支持行級鎖，也支持表級鎖，但默認
情況下采用行級鎖。
MySQL這3種鎖的特性可大致歸納如下：
（1）表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。
（2）行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。
（3）頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般。
僅從鎖的角度來說，表級鎖更適合於以查詢為主，只有少量按索引條件更新數據的應用，如Web應用；而行級鎖則
更適合於有大量按索引條件並發更新少量不同數據，同時又有並發查詢的應用，如一些在線事務處理系統。
一、MyISAM表鎖
1. 查詢表級鎖爭用情況
show status like 'table%'; 如果table_locks_waited 的值比較高，則說明存在着比較嚴重的表級鎖爭用情況。
2. MySQL表級鎖的鎖模式
MySQL 的表級鎖有兩種模式：表共享讀鎖和表獨占寫鎖。
當一個session對某個表加了讀鎖之后，該session只能訪問加鎖的這個表，而且只能進行讀操作；其他session可以對
這個表進行讀操作，但是進行寫操作會被阻塞，需要等待鎖的釋放。當一個session對某個表加了寫鎖之后，該session只能
訪問加鎖的這個表，可以進行讀操作和寫操作，其他session對這個表的讀和寫操作都會被阻塞，需要等待鎖的釋放。
MyISAM 表的讀操作與寫操作之間，以及寫操作之間是串行的。
3. 如何加表鎖
加讀鎖：lock table tbl_name read; 加寫鎖：lock table tbl_name write; 釋放鎖：unlock tables; MyISAM 在執行查詢語句前，會自動給涉及的所有表加讀鎖，在執行更新操作前，會自動給涉及的表加寫鎖， 這個過程並不需要用戶干預，因此，用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。給MyISAM表顯式 加鎖，一般是為了在一定程度模擬事務操作，實現對某一時間點多個表的一致性讀取。 注意，當使用LOCK TABLES時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現多少次， 就要通過與SQL語句中相同的別名鎖定多少次，否則也會出錯！
4. 並發插入
MyISAM存儲引擎有一個系統變量concurrent_insert，專門用以控制其並發插入的行為，其值分別可以為0、1或2。 （1）當concurrent_insert設置為0時，不允許並發插入。 （2）當concurrent_insert設置為1時，如果MyISAM表中沒有空洞（即表的中間沒有被刪除的行），MyISAM允許在 一個進程讀表的同時，另一個進程從表尾插入記錄。這也是MySQL的默認設置。 （3）當concurrent_insert設置為2時，無論MyISAM表中有沒有空洞，都允許在表尾並發插入記錄。 只需在加表鎖命令中加入“local”選項，即：lock table tbl_name local read，在滿足MyISAM表並發插入條件的情況下， 其他用戶就可以在表尾並發插入記錄，但更新操作會被阻塞，而且加鎖的用戶無法訪問到其他用戶並發插入的記錄。
5. MyISAM鎖調度
當寫進程和讀進程同時請求同一個MyISAM表的寫鎖和讀鎖是，寫進程會優先獲得鎖。不僅如此，即使讀請求先到 鎖等待隊列，寫請求后到，寫鎖也會插到讀鎖請求之前！這是因為MySQL認為寫請求一般比讀請求要重要。這也正是 MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因為大量的更新操作會造成查詢操作很難獲得讀鎖，從而 可能永遠阻塞。 通過一下一些設置調節MyISAM的調度行為： （1）通過指定啟動參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。 （2）通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先級降低。 （3）通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先級。 （4）給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值后，MySQL就暫時將寫請求的優 先級降低，給讀進程一定獲得鎖的機會。
二、InnoDB鎖問題
1. 查詢InnoDB行鎖爭用情況
show status like 'innodb_row_lock%'; 如果InnoDB_row_lock_waits和InnoDB_row_lock_time_avg的值比較高，說明鎖爭用比較嚴重，這時可以通過設 置InnoDB Monitors來進一步觀察發生鎖沖突的表、數據行等，並分析鎖爭用的原因。 打開監視器： CREATE TABLE innodb_monitor(a INT) ENGINE=INNODB; Show innodb status\G; 停止監視器： DROP TABLE innodb_monitor; 打開監視器以后，默認情況下每15 秒會向日志中記錄監控的內容，如果長時間打開會導致.err 文件變得非常的巨大， 所以用戶在確認問題原因之后，要記得刪除監控表以關閉監視器，或者通過使用“--console”選項來啟動服務器以關閉寫 日志文件。
2. InnoDB的行鎖及加鎖方法
InnoDB的行鎖有兩種：共享鎖（S）和排他鎖（X）。為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有 兩種內部使用的意向鎖：意向共享鎖和意向排他鎖，這兩種意向鎖都是表鎖。事務在給數據行加鎖之前必須先取得對應表 對應的意向鎖。 意向鎖是InnoDB自動加的，不需用戶干預。對於UPDATE、DELETE 和INSERT 語句，InnoDB會自動給涉及數據集加 排他鎖（X）；對於普通SELECT語句，InnoDB 不會加任何鎖；事務可以通過以下語句顯示給記錄集加共享鎖或排他鎖。 Set autocommit=0; 共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE。 排他鎖（X）：SELECT * FROM table_name WHERE ... FOR UPDATE。 釋放鎖：unlock tables;（會隱含提交事務） 當一個事務獲得一個表的共享鎖時，其他事務可以查詢該表的記錄，也可以對該記錄加共享鎖。當事務對表進行 更新操作時，若存在另一個事務也在該表加了共享鎖，則需要等待鎖的釋放，若另一個事務同時也對該表執行了更新操 作，則會導致死鎖，另一個事務退出，當前事務完成更新操作。當一個事務獲得一個表的排他鎖時，其他事務只能對該 表的記錄進行查詢，不能加共享鎖，也不能更新記錄，會出現等待。
3. InnoDB行鎖實現方式
InnoDB行鎖是通過給索引上的索引項加鎖來實現的，InnoDB 這種行鎖實現特點意味着： （1）只有通過索引條件檢索數據，InnoDB才使用行級鎖，否則，InnoDB 將使用表鎖。 （2）由於MySQL的行鎖是針對索引加的鎖，不是針對記錄加的鎖，所以雖然是訪問不同行的記錄，但是如果是使用 相同的索引鍵，是會出現鎖沖突的。 （3）當表有多個索引的時候，不同的事務可以使用不同的索引鎖定不同的行，另外，不論是使用主鍵索引、唯一索引 或普通索引，InnoDB 都會使用行鎖來對數據加鎖。（雖然使用的是不同的索引，但是如果記錄已經被其他session鎖定的 話也是需要等待的。） （4）即便在條件中使用了索引字段，但是否使用索引來檢索數據是由MySQL 通過判斷不同執行計划的代價來決定的， 如果MySQL 認為全表掃描效率更高，比如對一些很小的表，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是 行鎖。
4. 間隙鎖
當使用范圍條件檢索數據的時候，對於鍵值在條件范圍內但並不存在的記錄，InnoDB也會進行加鎖，這個鎖
就叫“間隙鎖”。InnoDB使用間隙鎖的目的，一方面是為了防止幻讀，另一方面是為了滿足恢復和復制的需要。但是
這種加鎖機制會阻塞符合條件范圍內鍵值的並發插入，造成嚴重的鎖等待，所以應該盡量避免使用范圍條件來檢索數據。
除了通過范圍條件加鎖時使用間隙鎖外，如果使用相等條件請求給一個不存在的記錄加鎖，InnoDB也會使用間隙鎖！
5. 恢復和復制的需要對InnoDB鎖機制的影響
MySQL通過BINLOG記錄執行成功的INSERT、UPDATE、DELETE等更新數據的SQL語句，並由此實現MySQL數據庫 的恢復和主從復制。MySQL的恢復機制（復制其實就是在Slave Mysql不斷做基於BINLOG的恢復）有以下特點： （1）MySQL的恢復是SQL語句級的，也就是重新執行BINLOG中的SQL語句。 （2）MySQL 的Binlog是按照事務提交的先后順序記錄的，恢復也是按這個順序進行的。 所以MySQL的恢復和復制對鎖機制的要求是：在一個事務未提交前，其他並發事務不能插入滿足其鎖定條件 的任何記錄，也就是不允許出現幻讀。 另外，對於一般的select語句，MySQL使用多版本數據來實現一致性，不需要加任何鎖，然而，對於“insert into target_tab select * from source_tab where ...”和“create table new_tab ...select ... From source_tab where ...”這種 SQL語句，用戶並沒有對source_tab做任何更新操作，但MySQL對這種SQL語句做了特別處理，給source_tab加了共享鎖。 這是因為，不加鎖的話，如果這個SQL語句執行期間，有另一個事務對source_tab做了更新並且先進行了提交，那么在 BINLOG中，更新操作的位置會在該SQL語句之前，使用這個BINLOG進行數據庫恢復的話，恢復的結果就會與實際的應 用邏輯不符，進行復制則會導致主從數據庫不一致。因為實際上應用插入target_tab或new_tab中的數據是另一個事務 對source_tab更新前的數據，而BINLOG記錄的卻是先進行更新再執行select...insert...語句。如果上述語句的SELECT是范 圍條件，InnoDB還會給源表加間隙鎖。所以這種SQL語句會阻塞對原表的並發更新，應盡量避免使用。
6. InnoDB使用表鎖的情況及注意事項
對於InnoDB表，在絕大部分情況下都應該使用行級鎖，但在個別特殊事務中，也可以考慮使用表級鎖，主要 有以下兩種情況： （1）事務需要更新大部分或全部數據，表又比較大，如果使用默認的行鎖，不僅這個事務執行效率低，而且可能造 成其他事務長時間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。 （2）事務涉及多個表，比較復雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的 表，從而避免死鎖、減少數據庫因事務回滾帶來的開銷。 另外，在InnoDB中使用表鎖需要注意以下兩點： （1）使用LOCK TABLES雖然可以給InnoDB加表級鎖，但表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層──MySQL Server負責的，僅當autocommit=0、innodb_table_locks=1（默認設置）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server也才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB 將無法自動檢測 並處理這種死鎖。 （2）在用LOCK TABLES 對InnoDB 表加鎖時要注意，要將AUTOCOMMIT 設為0，否則MySQL不會給表加鎖；事務結束前， 不要用UNLOCK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT 或ROLLBACK 並不能釋放用LOCK TABLES 加的表級鎖，必須用UNLOCK TABLES 釋放表鎖。
7. 關於死鎖
MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次獲得所需的全部鎖，要么全部滿足，要么等待，因此不會 出現死鎖。但在InnoDB 中，除單個SQL 組成的事務外，鎖是逐步獲得的，這就決定了在InnoDB 中發生死鎖是可能的。 發生死鎖后，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並回退，另一個事務獲得鎖，繼續完成事務。但在 涉及外部鎖，或涉及表鎖的情況下，InnoDB並不能完全自動檢測到死鎖，這需要通過設置鎖等待超時參數 innodb_lock_wait_timeout來解決。 通常來說，死鎖都是應用設計的問題，通過調整業務流程、數據庫對象設計、事務大小，以及訪問數據庫的SQL 語句，絕大部分死鎖都可以避免。下面就通過實例來介紹幾種避免死鎖的常用方法。 （1）在應用中，如果不同的程序會並發存取多個表，應盡量約定以相同的順序來訪問表，這樣可以大大降低產生死鎖 的機會。 （2）在程序以批量方式處理數據的時候，如果事先對數據排序，保證每個線程按固定的順序來處理記錄，也可以大大 降低出現死鎖的可能。 （3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應先申請共享鎖，更新時再申請排他鎖， 因為當用戶申請排他鎖時，其他事務可能又已經獲得了相同記錄的共享鎖，從而造成鎖沖突，甚至死鎖。 （4）在REPEATABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...FOR UPDATE加排他鎖，在沒有 符合該條件記錄情況下，兩個線程都會加鎖成功。程序發現記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么 做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可避免問題。 （5）當隔離級別為READ COMMITTED時，如果兩個線程都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄， 如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現鎖等待，當第1個線程提交后，第2個線程會 因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第3個線程又來申請排他鎖，也會出現死鎖。 對於這種情況，可以直接做插入操作，然后再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得 的排他鎖。