s鎖（共享鎖）
又稱讀鎖，若事務t對資料物件a加上s鎖，則事務t可以讀a但不能修改a，其他事務只能再對a加s鎖，而不能加x鎖，直到t釋放a上的s鎖。這保證了其他事務可以讀a，但在t釋放a上的s鎖之前不能對a做任何修改，除非先獲取a的x鎖。
x鎖（排他鎖）
又稱寫鎖，若事務t對資料物件a加上x鎖，事務t可以讀a也可以修改a，其他事務不能再對a加任何鎖，直到t釋放a上的鎖。這保證了其他事務在t釋放a上的鎖之前不能再讀取和修改a。
myisam只支援表鎖，鎖的是整張表，讀取資料的時候會加s鎖，增刪改的時候會加x鎖。
innodb既支援表鎖也支援行鎖，可以鎖行級別的資料，增刪改的時候會對資料物件（可能是一行或者多行或者一張表）加x鎖，讀取的時候一般不加鎖，因為innodb實現mvcc（multi-version concurrency control 多版本
併發控制）。後面我會出一篇部落格詳細講解innodb的鎖機制以及它的mvcc。
首先準備一張myisam的表。
為了模擬高併發場景我們可以手動加鎖（如果不手動加鎖，他也會隱式的自動加鎖和自動釋放鎖）
lock table name read; 給name表加s鎖
lock table name write; 給name表加x鎖
也可以一次性給多張表加鎖
lock table name1 read,name2 write;
釋放所有獲得的鎖
unlock tables;
測試一：測試mb表的s鎖和x鎖
可以看到，兩個會話都成功資料物件加了s鎖。
但是會話1不能更新資料。除非讓第二個會話放棄s鎖，然後第乙個會話再加x鎖，獲取鎖成功後才能更新資料。如果鎖被其他會話占用 而沒有獲取成功的話會話1會一直等待獲取，直到達到設定的超時時間。
測試二：加了x鎖真的就立馬不能讀取資料嗎？
如果會話1對資料物件加了x鎖，但是這個時候還沒有修改資料，而會話2卻查詢了資料，還是有可能可以獲取資料的，但是一但會話1修改了資料那麼會話2就不能再獲取資料了，必須等會話1釋放x鎖。這個其實很好理解，mysql底層是有個查詢快取的，當我們會話1沒有修改資料的時候如果查詢快取當中有資料，那麼這個資料是有效的，一但會話1修改了資料這個時候查詢快取就無效了，這樣設計可以提公升一點效率，而又不違背x鎖和s鎖的設計的原則。
可以看到，我們先把mb表給鎖了，然後查詢資料，這個時候會話1沒有修改資料，但是會話2也沒有查詢快取所以仍然查詢不了資料。
接下來我們再測試。先讓會話2先查詢一次資料，然後會話1在加x鎖，然後會話2再傳送同樣的sql語句。
可以看到還是成功的獲取了資料。那如果這個時候會話1修改了mb表的資料呢？
可以看到，會話2的查詢語句一直在等待，直到會話1釋放x鎖。
當會話1釋放了x鎖會話2也就順利執行了查詢語句。
當會話1獲取了a表的x鎖，會話2獲取了b表的x鎖，而會話1又在嘗試獲取b表的x鎖，會話2在嘗試獲取a表的x鎖，這個時候就發生死鎖了。
但是一般這種情況不會存在的，因為myisam不支援事務，相當於每一條sql就是乙個事務，當某個會話執行完一條語句之後會立馬把鎖給釋放，並不會把鎖保留，也就是說不存在同時需要占用兩個鎖的情況。當然我們可以手動加鎖模擬這個場景。
在myisam下，當發生死鎖時，mysql會自動把會話持有的鎖給釋放。
會話1的ma的x鎖被釋放給了會話2，會話2的mb的x鎖釋放給了會話1。
當然在實際做專案的時候也不會去這樣做，一般不會手動加鎖而是讓會話執行sql語句的時候自動加鎖和自動釋放鎖。
前面所有的測試在innodb上有同樣的效果，因為innodb一樣支援表鎖。
參考文章
MySQL鎖概述 MyISAM 表鎖
相對其他資料庫而言，mysql的鎖機制比較簡單，其最顯著的特點是不同的儲存引擎支援不同的鎖機制。比如，myisam和memory儲存引擎採用的是表級鎖 table level locking bdb儲存引擎採用的是頁面鎖 page level locking 但也支援表級鎖 innodb儲存引擎既支...
mysql 讀寫鎖 表鎖myisam
讀鎖 session1 lock table book read unlock tables session1可以讀book 不可以寫book 也不可以讀寫其它表 session2可以讀book 也可以讀寫其它表 可以寫book 但阻塞的需要session1解鎖後unlock tables 寫鎖 s...
鎖（MySQL篇） 之MyISAM表鎖
鎖是計算機協調多個程序或執行緒併發訪問某一資源的機制，在資料庫中，除傳統的計算資源 如cpu ram i o等 的爭用以外，資料也是一種供許多使用者共享的資源。如何保證資料併發訪問的一致性 有效性是所有資料庫必須解決的乙個問題，鎖衝突也是影響資料庫併發訪問的乙個重要因素。相比其他資料庫而言，mysq...