mysql資料庫的鎖機制

❶ mysql中的鎖都有哪些

MySQL 中有哪些鎖？

資料庫中鎖的設計初衷處理並發問題，作為多用戶共享資源，當出現並發訪問的時候，資料庫需要合理控制資源訪問規則。鎖就是實現這些訪問規則中的重要數據。

鎖的分類

根據加鎖范圍，MySQL 裡面的鎖可以分成 全局鎖 、 表級鎖 、 行鎖 三類。

全局鎖

全局鎖，就是對整個資料庫實例加鎖，MySQL 提供了一個加全局讀鎖的方法，命令是:

Flush tables with read lock (FTWRL)

當需要整個庫只讀狀態的時候，可以使用這個命令，之後其他線程的：數據更新語句（增刪改），數據定義語句（建表，修改表結構）和更新事務的提交語句將會被阻塞。

全局鎖的使用場景

全局鎖的定型使用場景，做 全庫邏輯備份 。也就是把整個庫每個表都 Select 出來，然後存成文本。

如何整個庫都只讀，會有什麼問題？ 如果你在主庫上備份，那麼在備份期間都不能執行更想，業務就基本上停擺。 如果在從庫上備份，那麼備份期間從庫不能執行主庫同步過來的 binlog ,會導致從延遲。 既然要全庫只讀， 為什麼不使用set global readonly=true的方式呢?

readonly 方式也可以讓全庫進入只讀狀態,但我還是會建議你用FTWRL方式， 主要有兩個原因：

一是， 在有些系統中， readonly的值會被用來做其他邏輯，比如用來判斷一個庫是主庫還是備庫。因此，修改global變數的方式影響面更大， 我不建議你使用。 二是， 在異常處理機制上有差異。如果執行FTWRL命令之後由於客戶端發生異常斷開， 那麼MySQL會自動釋放這個全局鎖， 整個庫回到可以正常更新的狀態。而將整個庫設置為readonly之後， 如果客戶端發生異常， 則資料庫就會一直保持readonly狀態， 這樣會導致整個庫長時間處於不可寫狀態， 風險較高 表級別鎖

MySQL 裡面表級別的鎖有兩種：一種是表鎖，一種是元數據鎖（meta data lok, MDL）。表鎖的語法是 ：

lock tables ... read/write

與 FTWRL 類似,可以使用 unlock tables 主動釋放鎖，也可以在客戶端斷開的時候自動釋放。需要注意的是，lock tables語法除了會限制別的線程的讀寫外，也限定了本線程接下來的操作對象。

MDL 表級鎖

MDL 不需要顯示使用，在訪問一個表的時候自動加上， MDL 保證讀寫的正確性，也就是說在查詢數據時，不允許有其他線程對這個表結構做變更。

什麼操作會加 MDL 鎖？

在MySQL 5.5版本中引入了MDL， 當對一個表做增刪改查操作的時候，加 MDL讀鎖 ；當要對表做結構變更操作的時候，加 MDL寫鎖 。

讀鎖之間不互斥，因此可以有多個線程同時對一張表增刪改查。 讀寫之間、寫鎖之間是互斥的，用來保證變更表結構操作的安全性，如果有兩個線程要同時給一個表加欄位，其中一個要等另外一個執行完才能執行。 更改表結構要注意哪些？

給一個表加欄位， 或者修改欄位， 或者加索引， 需要掃描全表的數據。在對大表操作的時候， 你肯定會特別小心， 以免對線上服務造成影響。而實際上， 即使是小表， 操作不慎也會出問題，導致整個庫的線程爆滿。

舉個例子

我們來看一下下面的操作序列， 假設表t是一個小表。

image

session A先啟動， 這時候會對表t加一個 MDL讀鎖 。由於session B需要的也是 MDL讀鎖 ， 因此可以正常執行。 session C會被blocked， 是因為session A的MDL讀鎖還沒有釋放， 而session C需要MDL寫鎖， 因此只能被阻塞，讀寫鎖互斥。 如果只有session C自己被阻塞還沒什麼關系， 但是之後所有要在表t上新申請MDL讀鎖的請求也會被session C阻塞。前面我們說了，所有對表的增刪改查操作都需要先申請MDL讀鎖， 就都被鎖住， 等於這個表現在完全不可讀寫了。

如果某個表上的查詢語句頻繁， 而且客戶端有重試機制，也就是說超時後會再起一個新session 再請求的話， 這個 庫的線程很快就會爆滿 。事務中的MDL鎖， 在語句執行開始時申請， 但是語句結束後並不會馬上釋放， 而會等到整個事務提交後再釋放。

怎麼解決這個 更改表結構問題

比較理想的機制是， 在alter table語句裡面設定等待時間， 如果在這個指定的等待時間裡面能夠拿到MDL寫鎖最好， 拿不到也不要阻塞後面的業務語句， 先放棄。

ALTER TABLE tbl_name NOWAIT add column ... ALTER TABLE tbl_name WAIT N add column ...

❷ mysql什麼是悲觀鎖和樂觀鎖

悲觀鎖(Pessimistic Lock), 顧名思義，就是很悲觀，每次去拿數據的時候都認為別人會修改，所以每次在拿數據的時候都會上鎖，這樣別人想拿這個數據就會block直到它拿到鎖。傳統的關系型資料庫里邊就用到了很多這種鎖機制，比如行鎖，表鎖等，讀鎖，寫鎖等，都是在做操作之前先上鎖。
樂觀鎖(Optimistic Lock), 顧名思義，就是很樂觀，每次去拿數據的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據，可以使用版本號等機制。樂觀鎖適用於多讀的應用類型，這樣可以提高吞吐量，像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。

❸ 關於MySQL中的表鎖和行鎖

mysql行鎖和表鎖

鎖是計算機協調多個進程或純線程並發訪問某一資源的機制。在資料庫中，除傳統的計算資源（CPU、RAM、I/O）的爭用以外，數據也是一種供許多用戶共享的資源。如何保證數據並發訪問的一致性、有效性是所在有資料庫必須解決的一個問題，鎖沖突也是影響資料庫並發訪問性能的一個重要因素。從這個角度來說，鎖對資料庫而言顯得尤其重要，也更加復雜。

概述

相對其他資料庫而言，MySQL的鎖機制比較簡單，其最顯著的特點是不同的存儲引擎支持不同的鎖機制。

MySQL大致可歸納為以下3種鎖：

1. 表級鎖：開銷小，加鎖快；不會出現死鎖；鎖定粒度大，發生鎖沖突的概率最高，並發度最低。

2. 行級鎖：開銷大，加鎖慢；會出現死鎖；鎖定粒度最小，發生鎖沖突的概率最低，並發度也最高。

3. 頁面鎖：開銷和加鎖時間界於表鎖和行鎖之間；會出現死鎖；鎖定粒度界於表鎖和行鎖之間，並發度一般

MySQL表級鎖的鎖模式（MyISAM)

MySQL表級鎖有兩種模式：表共享鎖（Table Read Lock）和表獨占寫鎖（Table Write Lock）。

1. 對MyISAM的讀操作，不會阻塞其他用戶對同一表請求，但會阻塞對同一表的寫請求；

2. 對MyISAM的寫操作，則會阻塞其他用戶對同一表的讀和寫操作；

3. MyISAM表的讀操作和寫操作之間，以及寫操作之間是串列的。

當一個線程獲得對一個表的寫鎖後，只有持有鎖線程可以對表進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放為止。

MySQL表級鎖的鎖模式

MySQL的表鎖有兩種模式：表共享讀鎖（Table Read Lock）和表獨占寫鎖（Table Write Lock）。鎖模式的兼容如下表

MySQL中的表鎖兼容性

當前鎖模式/是否兼容/請求鎖模式

讀鎖 是 是 否

寫鎖 是 否 否

可見，對MyISAM表的讀操作，不會阻塞其他用戶對同一表的讀請求，但會阻塞對同一表的寫請求；對MyISAM表的寫操作，則會阻塞其他用戶對同一表的讀和寫請求；MyISAM表的讀和寫操作之間，以及寫和寫操作之間是串列的！（當一線程獲得對一個表的寫鎖後，只有持有鎖的線程可以對表進行更新操作。其他線程的讀、寫操作都會等待，直到鎖被釋放為止。）

如何加表鎖

MyISAM在執行查詢語句（SELECT）前，會自動給涉及的所有表加讀鎖，在執行更新操作（UPDATE、DELETE、INSERT等）前，會自動給涉及的表加寫鎖，這個過程並不需要用戶干預，因此用戶一般不需要直接用LOCK TABLE命令給MyISAM表顯式加鎖。在本書的示例中，顯式加鎖基本上都是為了方便而已，並非必須如此。

給MyISAM表顯示加鎖，一般是為了一定程度模擬事務操作，實現對某一時間點多個表的一致性讀取。

要特別說明以下兩點內容。

• 上面的例子在LOCK TABLES時加了『local』選項，其作用就是在滿足MyISAM表並發插入條件的情況下，允許其他用戶在表尾插入記錄

• 在用LOCKTABLES給表顯式加表鎖是時，必須同時取得所有涉及表的鎖，並且MySQL支持鎖升級。也就是說，在執行LOCK TABLES後，只能訪問顯式加鎖的這些表，不能訪問未加鎖的表；同時，如果加的是讀鎖，那麼只能執行查詢操作，而不能執行更新操作。其實，在自動加鎖的情況下也基本如此，MySQL問題一次獲得SQL語句所需要的全部鎖。這也正是MyISAM表不會出現死鎖（Deadlock Free）的原因

一個session使用LOCK TABLE 命令給表film_text加了讀鎖，這個session可以查詢鎖定表中的記錄，但更新或訪問其他表都會提示錯誤；同時，另外一個session可以查詢表中的記錄，但更新就會出現鎖等待。

當使用LOCK TABLE時，不僅需要一次鎖定用到的所有表，而且，同一個表在SQL語句中出現多少次，就要通過與SQL語句中相同的別名鎖多少次，否則也會出錯！

並發鎖

在一定條件下，MyISAM也支持查詢和操作的並發進行。

MyISAM存儲引擎有一個系統變數concurrent_insert，專門用以控制其並發插入的行為，其值分別可以為0、1或2。

• 當concurrent_insert設置為0時，不允許並發插入。

• 當concurrent_insert設置為1時，如果MyISAM允許在一個讀表的同時，另一個進程從表尾插入記錄。這也是MySQL的默認設置。

• 當concurrent_insert設置為2時，無論MyISAM表中有沒有空洞，都允許在表尾插入記錄，都允許在表尾並發插入記錄。

可以利用MyISAM存儲引擎的並發插入特性，來解決應用中對同一表查詢和插入鎖爭用。例如，將concurrent_insert系統變數為2，總是允許並發插入；同時，通過定期在系統空閑時段執行OPTIONMIZE TABLE語句來整理空間碎片，收到因刪除記錄而產生的中間空洞。

MyISAM的鎖調度

前面講過，MyISAM存儲引擎的讀和寫鎖是互斥，讀操作是串列的。那麼，一個進程請求某個MyISAM表的讀鎖，同時另一個進程也請求同一表的寫鎖，MySQL如何處理呢？答案是寫進程先獲得鎖。不僅如此，即使讀進程先請求先到鎖等待隊列，寫請求後到，寫鎖也會插到讀請求之前！這是因為MySQL認為寫請求一般比讀請求重要。這也正是MyISAM表不太適合於有大量更新操作和查詢操作應用的原因，因為，大量的更新操作會造成查詢操作很難獲得讀鎖，從而可能永遠阻塞。這種情況有時可能會變得非常糟糕！幸好我們可以通過一些設置來調節MyISAM的調度行為。

• 通過指定啟動參數low-priority-updates，使MyISAM引擎默認給予讀請求以優先的權利。

• 通過執行命令SET LOW_PRIORITY_UPDATES=1，使該連接發出的更新請求優先順序降低。

• 通過指定INSERT、UPDATE、DELETE語句的LOW_PRIORITY屬性，降低該語句的優先順序。

雖然上面3種方法都是要麼更新優先，要麼查詢優先的方法，但還是可以用其來解決查詢相對重要的應用（如用戶登錄系統）中，讀鎖等待嚴重的問題。

另外，MySQL也提供了一種折中的辦法來調節讀寫沖突，即給系統參數max_write_lock_count設置一個合適的值，當一個表的讀鎖達到這個值後，MySQL變暫時將寫請求的優先順序降低，給讀進程一定獲得鎖的機會。

上面已經討論了寫優先調度機制和解決辦法。這里還要強調一點：一些需要長時間運行的查詢操作，也會使寫進程「餓死」！因此，應用中應盡量避免出現長時間運行的查詢操作，不要總想用一條SELECT語句來解決問題。因為這種看似巧妙的SQL語句，往往比較復雜，執行時間較長，在可能的情況下可以通過使用中間表等措施對SQL語句做一定的「分解」，使每一步查詢都能在較短時間完成，從而減少鎖沖突。如果復雜查詢不可避免，應盡量安排在資料庫空閑時段執行，比如一些定期統計可以安排在夜間執行。

InnoDB鎖問題

InnoDB與MyISAM的最大不同有兩點：一是支持事務（TRANSACTION）；二是採用了行級鎖。

行級鎖和表級鎖本來就有許多不同之處，另外，事務的引入也帶來了一些新問題。

1.事務（Transaction）及其ACID屬性

事務是由一組SQL語句組成的邏輯處理單元，事務具有4屬性，通常稱為事務的ACID屬性。

• 原性性（Actomicity）：事務是一個原子操作單元，其對數據的修改，要麼全都執行，要麼全都不執行。

• 一致性（Consistent）：在事務開始和完成時，數據都必須保持一致狀態。這意味著所有相關的數據規則都必須應用於事務的修改，以操持完整性；事務結束時，所有的內部數據結構（如B樹索引或雙向鏈表）也都必須是正確的。

• 隔離性（Isolation）：資料庫系統提供一定的隔離機制，保證事務在不受外部並發操作影響的「獨立」環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。

• 持久性（Durable）：事務完成之後，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。

2.並發事務帶來的問題

相對於串列處理來說，並發事務處理能大大增加資料庫資源的利用率，提高資料庫系統的事務吞吐量，從而可以支持可以支持更多的用戶。但並發事務處理也會帶來一些問題，主要包括以下幾種情況。

• 更新丟失（Lost Update）：當兩個或多個事務選擇同一行，然後基於最初選定的值更新該行時，由於每個事務都不知道其他事務的存在，就會發生丟失更新問題——最後的更新覆蓋了其他事務所做的更新。例如，兩個編輯人員製作了同一文檔的電子副本。每個編輯人員獨立地更改其副本，然後保存更改後的副本，這樣就覆蓋了原始文檔。最後保存其更改保存其更改副本的編輯人員覆蓋另一個編輯人員所做的修改。如果在一個編輯人員完成並提交事務之前，另一個編輯人員不能訪問同一文件，則可避免此問題

• 臟讀（Dirty Reads）：一個事務正在對一條記錄做修改，在這個事務並提交前，這條記錄的數據就處於不一致狀態；這時，另一個事務也來讀取同一條記錄，如果不加控制，第二個事務讀取了這些「臟」的數據，並據此做進一步的處理，就會產生未提交的數據依賴關系。這種現象被形象地叫做「臟讀」。

• 不可重復讀（Non-Repeatable Reads）：一個事務在讀取某些數據已經發生了改變、或某些記錄已經被刪除了！這種現象叫做「不可重復讀」。

• 幻讀（Phantom Reads）：一個事務按相同的查詢條件重新讀取以前檢索過的數據，卻發現其他事務插入了滿足其查詢條件的新數據，這種現象就稱為「幻讀」。

3.事務隔離級別

在並發事務處理帶來的問題中，「更新丟失」通常應該是完全避免的。但防止更新丟失，並不能單靠資料庫事務控制器來解決，需要應用程序對要更新的數據加必要的鎖來解決，因此，防止更新丟失應該是應用的責任。

「臟讀」、「不可重復讀」和「幻讀」，其實都是資料庫讀一致性問題，必須由資料庫提供一定的事務隔離機制來解決。資料庫實現事務隔離的方式，基本可以分為以下兩種。

一種是在讀取數據前，對其加鎖，阻止其他事務對數據進行修改。

另一種是不用加任何鎖，通過一定機制生成一個數據請求時間點的一致性數據快照（Snapshot），並用這個快照來提供一定級別（語句級或事務級）的一致性讀取。從用戶的角度，好像是資料庫可以提供同一數據的多個版本，因此，這種技術叫做數據多版本並發控制（MultiVersion Concurrency Control，簡稱MVCC或MCC），也經常稱為多版本資料庫。

資料庫的事務隔離級別越嚴格，並發副作用越小，但付出的代價也就越大，因為事務隔離實質上就是使事務在一定程度上「串列化」進行，這顯然與「並發」是矛盾的，同時，不同的應用對讀一致性和事務隔離程度的要求也是不同的，比如許多應用對「不可重復讀」和「幻讀」並不敏感，可能更關心數據並發訪問的能力。

為了解決「隔離」與「並發」的矛盾，ISO/ANSI SQL92定義了4個事務隔離級別，每個級別的隔離程度不同，允許出現的副作用也不同，應用可以根據自己業務邏輯要求，通過選擇不同的隔離級別來平衡＂隔離＂與＂並發＂的矛盾

事務4種隔離級別比較

隔離級別/讀數據一致性及允許的並發副作用 讀數據一致性 臟讀 不可重復讀 幻讀

未提交讀（Read uncommitted）

• 最低級別，只能保證不讀取物理上損壞的數據 是 是 是

已提交度（Read committed） 語句級 否 是 是

可重復讀（Repeatable read） 事務級 否 否 是

可序列化（Serializable） 最高級別，事務級 否 否 否

最後要說明的是：各具體資料庫並不一定完全實現了上述4個隔離級別，例如，Oracle只提供Read committed和Serializable兩個標准級別，另外還自己定義的Read only隔離級別：SQL Server除支持上述ISO/ANSI SQL92定義的4個級別外，還支持一個叫做＂快照＂的隔離級別，但嚴格來說它是一個用MVCC實現的Serializable隔離級別。MySQL支持全部4個隔離級別，但在具體實現時，有一些特點，比如在一些隔離級下是採用MVCC一致性讀，但某些情況又不是。

獲取InonoD行鎖爭用情況

可以通過檢查InnoDB_row_lock狀態變數來分析系統上的行鎖的爭奪情況：

如果發現爭用比較嚴重，如Innodb_row_lock_waits和Innodb_row_lock_time_avg的值比較高，還可以通過設置InnoDB Monitors來進一步觀察發生鎖沖突的表、數據行等，並分析鎖爭用的原因。

InnoDB的行鎖模式及加鎖方法

InnoDB實現了以下兩種類型的行鎖。

• 共享鎖（s）：允許一個事務去讀一行，阻止其他事務獲得相同數據集的排他鎖。

• 排他鎖（X）：允許獲取排他鎖的事務更新數據，阻止其他事務取得相同的數據集共享讀鎖和排他寫鎖。

另外，為了允許行鎖和表鎖共存，實現多粒度鎖機制，InnoDB還有兩種內部使用的意向鎖（Intention Locks），這兩種意向鎖都是表鎖。

意向共享鎖（IS）：事務打算給數據行共享鎖，事務在給一個數據行加共享鎖前必須先取得該表的IS鎖。

意向排他鎖（IX）：事務打算給數據行加排他鎖，事務在給一個數據行加排他鎖前必須先取得該表的IX鎖。

InnoDB行鎖模式兼容性列表

如果一個事務請求的鎖模式與當前的鎖兼容，InnoDB就請求的鎖授予該事務；反之，如果兩者兩者不兼容，該事務就要等待鎖釋放。

意向鎖是InnoDB自動加的，不需用戶干預。對於UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及及數據集加排他鎖（X）；對於普通SELECT語句，InnoDB會自動給涉及數據集加排他鎖（X）；對於普通SELECT語句，InnoDB不會任何鎖；事務可以通過以下語句顯示給記錄集加共享鎖或排鎖。

共享鎖（S）：SELECT * FROM table_name WHERE ... LOCK IN SHARE MODE

排他鎖（X）：SELECT * FROM table_name WHERE ...FOR UPDATE

用SELECT .. IN SHARE MODE獲得共享鎖，主要用在需要數據依存關系時確認某行記錄是否存在，並確保沒有人對這個記錄進行UPDATE或者DELETE操作。但是如果當前事務也需要對該記錄進行更新操作，則很有可能造成死鎖，對於鎖定行記錄後需要進行更新操作的應用，應該使用SELECT ... FOR UPDATE方式獲取排他鎖。

InnoDB行鎖實現方式

InnoDB行鎖是通過索引上的索引項來實現的，這一點MySQL與Oracle不同，後者是通過在數據中對相應數據行加鎖來實現的。InnoDB這種行鎖實現特點意味者：只有通過索引條件檢索數據，InnoDB才會使用行級鎖，否則，InnoDB將使用表鎖！

在實際應用中，要特別注意InnoDB行鎖的這一特性，不然的話，可能導致大量的鎖沖突，從而影響並發性能。

什麼時候使用表鎖

對於InnoDB表，在絕大部分情況下都應該使用行級鎖，因為事務和行鎖往往是我們之所以選擇InnoDB表的理由。但在個另特殊事務中，也可以考慮使用表級鎖。

• 第一種情況是：事務需要更新大部分或全部數據，表又比較大，如果使用默認的行鎖，不僅這個事務執行效率低，而且可能造成其他事務長時間鎖等待和鎖沖突，這種情況下可以考慮使用表鎖來提高該事務的執行速度。

• 第二種情況是：事務涉及多個表，比較復雜，很可能引起死鎖，造成大量事務回滾。這種情況也可以考慮一次性鎖定事務涉及的表，從而避免死鎖、減少資料庫因事務回滾帶來的開銷。

當然，應用中這兩種事務不能太多，否則，就應該考慮使用MyISAM表。

在InnoDB下 ，使用表鎖要注意以下兩點。

（1）使用LOCK TALBES雖然可以給InnoDB加表級鎖，但必須說明的是，表鎖不是由InnoDB存儲引擎層管理的，而是由其上一層MySQL Server負責的，僅當autocommit=0、innodb_table_lock=1（默認設置）時，InnoDB層才能知道MySQL加的表鎖，MySQL Server才能感知InnoDB加的行鎖，這種情況下，InnoDB才能自動識別涉及表級鎖的死鎖；否則，InnoDB將無法自動檢測並處理這種死鎖。

（2）在用LOCAK TABLES對InnoDB鎖時要注意，要將AUTOCOMMIT設為0，否則MySQL不會給表加鎖；事務結束前，不要用UNLOCAK TABLES釋放表鎖，因為UNLOCK TABLES會隱含地提交事務；COMMIT或ROLLBACK產不能釋放用LOCAK TABLES加的表級鎖，必須用UNLOCK TABLES釋放表鎖，正確的方式見如下語句。

關於死鎖

MyISAM表鎖是deadlock free的，這是因為MyISAM總是一次性獲得所需的全部鎖，要麼全部滿足，要麼等待，因此不會出現死鎖。但是在InnoDB中，除單個SQL組成的事務外，鎖是逐步獲得的，這就決定了InnoDB發生死鎖是可能的。

發生死鎖後，InnoDB一般都能自動檢測到，並使一個事務釋放鎖並退回，另一個事務獲得鎖，繼續完成事務。但在涉及外部鎖，或涉及鎖的情況下，InnoDB並不能完全自動檢測到死鎖，這需要通過設置鎖等待超時參數innodb_lock_wait_timeout來解決。需要說明的是，這個參數並不是只用來解決死鎖問題，在並發訪問比較高的情況下，如果大量事務因無法立即獲取所需的鎖而掛起，會佔用大量計算機資源，造成嚴重性能問題，甚至拖垮資料庫。我們通過設置合適的鎖等待超時閾值，可以避免這種情況發生。

通常來說，死鎖都是應用設計的問題，通過調整業務流程、資料庫對象設計、事務大小、以及訪問資料庫的SQL語句，絕大部分都可以避免。下面就通過實例來介紹幾種死鎖的常用方法。

（1）在應用中，如果不同的程序會並發存取多個表，應盡量約定以相同的順序為訪問表，這樣可以大大降低產生死鎖的機會。如果兩個session訪問兩個表的順序不同，發生死鎖的機會就非常高！但如果以相同的順序來訪問，死鎖就可能避免。

（2）在程序以批量方式處理數據的時候，如果事先對數據排序，保證每個線程按固定的順序來處理記錄，也可以大大降低死鎖的可能。

（3）在事務中，如果要更新記錄，應該直接申請足夠級別的鎖，即排他鎖，而不應該先申請共享鎖，更新時再申請排他鎖，甚至死鎖。

（4）在REPEATEABLE-READ隔離級別下，如果兩個線程同時對相同條件記錄用SELECT...ROR UPDATE加排他鎖，在沒有符合該記錄情況下，兩個線程都會加鎖成功。程序發現記錄尚不存在，就試圖插入一條新記錄，如果兩個線程都這么做，就會出現死鎖。這種情況下，將隔離級別改成READ COMMITTED，就可以避免問題。

（5）當隔離級別為READ COMMITED時，如果兩個線程都先執行SELECT...FOR UPDATE，判斷是否存在符合條件的記錄，如果沒有，就插入記錄。此時，只有一個線程能插入成功，另一個線程會出現鎖等待，當第1個線程提交後，第2個線程會因主鍵重出錯，但雖然這個線程出錯了，卻會獲得一個排他鎖！這時如果有第3個線程又來申請排他鎖，也會出現死鎖。對於這種情況，可以直接做插入操作，然後再捕獲主鍵重異常，或者在遇到主鍵重錯誤時，總是執行ROLLBACK釋放獲得的排他鎖。

盡管通過上面的設計和優化等措施，可以大減少死鎖，但死鎖很難完全避免。因此，在程序設計中總是捕獲並處理死鎖異常是一個很好的編程習慣。

如果出現死鎖，可以用SHOW INNODB STATUS命令來確定最後一個死鎖產生的原因和改進措施。

總結

對於MyISAM的表鎖，主要有以下幾點

（1）共享讀鎖（S）之間是兼容的，但共享讀鎖（S）和排他寫鎖（X）之間，以及排他寫鎖之間（X）是互斥的，也就是說讀和寫是串列的。

（2）在一定條件下，MyISAM允許查詢和插入並發執行，我們可以利用這一點來解決應用中對同一表和插入的鎖爭用問題。

（3）MyISAM默認的鎖調度機制是寫優先，這並不一定適合所有應用，用戶可以通過設置LOW_PRIPORITY_UPDATES參數，或在INSERT、UPDATE、DELETE語句中指定LOW_PRIORITY選項來調節讀寫鎖的爭用。

（4）由於表鎖的鎖定粒度大，讀寫之間又是串列的，因此，如果更新操作較多，MyISAM表可能會出現嚴重的鎖等待，可以考慮採用InnoDB表來減少鎖沖突。

對於InnoDB表，主要有以下幾點

（1）InnoDB的行銷是基於索引實現的，如果不通過索引訪問數據，InnoDB會使用表鎖。

（2）InnoDB間隙鎖機制，以及InnoDB使用間隙鎖的原因。

（3）在不同的隔離級別下，InnoDB的鎖機制和一致性讀策略不同。

（4）MySQL的恢復和復制對InnoDB鎖機制和一致性讀策略也有較大影響。

（5）鎖沖突甚至死鎖很難完全避免。

在了解InnoDB的鎖特性後，用戶可以通過設計和SQL調整等措施減少鎖沖突和死鎖，包括：

• 盡量使用較低的隔離級別

• 精心設計索引，並盡量使用索引訪問數據，使加鎖更精確，從而減少鎖沖突的機會。

• 選擇合理的事務大小，小事務發生鎖沖突的幾率也更小。

• 給記錄集顯示加鎖時，最好一次性請求足夠級別的鎖。比如要修改數據的話，最好直接申請排他鎖，而不是先申請共享鎖，修改時再請求排他鎖，這樣容易產生死鎖。

• 不同的程序訪問一組表時，應盡量約定以相同的順序訪問各表，對一個表而言，盡可能以固定的順序存取表中的行。這樣可以大減少死鎖的機會。

• 盡量用相等條件訪問數據，這樣可以避免間隙鎖對並發插入的影響。

• 不要申請超過實際需要的鎖級別；除非必須，查詢時不要顯示加鎖。

• 對於一些特定的事務，可以使用表鎖來提高處理速度或減少死鎖的可能

❹ php mysql的鎖機制 怎麼寫

MYSQL中的鎖：
語法 ：
LOCK TABLE 表名1 READ|WRITE, 表名2 READ|WRITE .................. 【鎖表】
UNLOCK TABLES 【釋放表】

Read:讀鎖|共享鎖 ： 所有的客戶端只能讀這個表不能寫這個表
Write:寫鎖|排它鎖： 所有當前鎖定客戶端可以操作這個表，其他客戶端只能阻塞
注意：在鎖表的過程中只能操作被鎖定的表，如果要操作其他表，必須把所有要操作的表都鎖定起來！

PHP中的文件鎖 （鎖的是文件，不是表）
文件鎖的文件與表有什麼關系？：一點關系也沒有，與令牌相似，誰拿到誰操作。所以表根本沒鎖。
測試時，有個文件就行，叫什麼名無所謂

❺ mysql鎖定了資料庫表只能寫，為什麼還可以讀

鎖的作用，就是把許可權歸為私有，其它人用不了。你自已把表鎖了，自已當然還能用。

1、表級別的鎖定是MySQL各存儲引擎中最大顆粒度的鎖定機制。該鎖定機制最大的特點是實現邏輯非常簡單，帶來的系統負面影響最小。所以獲取鎖和釋放鎖的速度很快。由於表級鎖一次會將整個表鎖定，所以可以很好的避免困擾我們的死鎖問題。

2、資料庫鎖定機制簡單來說就是資料庫為了保證數據的一致性而使各種共享資源在被並發訪問訪問變得有序所設計的一種規則。

3、對於任何一種資料庫來說都需要有相應的鎖定機制，所以MySQL自然也不能例外。

4、MySQL資料庫由於其自身架構的特點，存在多種數據存儲引擎，每種存儲引擎所針對的應用場景特點都不太一樣，為了滿足各自特定應用場景的需求，每種存儲引擎的鎖定機制都是為各自所面對的特定場景而優化設計，所以各存儲引擎的鎖定機制也有較大區別。

5、總的來說，MySQL各存儲引擎使用了三種類型（級別）的鎖定機制：行級鎖定，頁級鎖定和表級鎖定。下面我們先分析一下MySQL這三種鎖定的特點和各自的優劣所在。