?

目錄

?

1.MySQL 鎖的類型有哪些呢？

2.如何使用全局鎖

3.如果要全庫只讀，為什么不使用set global readonly=true的方式？

4.表級鎖和行級鎖有什么區(qū)別？

5.行級鎖的使用有什么注意事項？

6.InnoDB 有哪幾類行鎖？

7.什么是共享鎖和排他鎖

8.意向鎖有什么作用？

9.當(dāng)前讀和快照讀有什么區(qū)別？

10.自增鎖有了解嗎？

11.如何處理死鎖問題？

---

1.MySQL 鎖的類型有哪些呢？

MySQL 中常見的鎖類型可以分為全局鎖、表級鎖和行鎖。下面分別介紹它們：

1. 全局鎖（Global Lock）：鎖定整個 MySQL 實例，用于執(zhí)行全局操作時，比如備份整個數(shù)據(jù)庫。全局鎖會阻塞所有對數(shù)據(jù)庫的操作，因此在使用全局鎖時需要慎重考慮。

2. 表級鎖（Table-level Lock）：鎖定整張表，適用于只有少量訪問，或者需要鎖定整張表時。表級鎖分為讀鎖（共享鎖）和寫鎖（排他鎖）。

   • 共享鎖（Shared Lock）：允許多個事務(wù)同時讀取同一張表，但是不能進(jìn)行寫操作。如果一個事務(wù)持有共享鎖，其他事務(wù)也可以持有共享鎖。共享鎖之間不會互相阻塞。

   • 排他鎖（Exclusive Lock）：只允許一個事務(wù)進(jìn)行寫操作，其他事務(wù)不能進(jìn)行讀取或?qū)懭氩僮鳌Ｈ绻粋€事務(wù)持有排他鎖，其他事務(wù)無法獲得共享鎖或排他鎖。排他鎖會阻塞其他事務(wù)的讀寫操作，因此需要慎重使用。

3. 行級鎖（Row-level Lock）：鎖定表中的某一行，用于控制對表中某一行的并發(fā)訪問。行級鎖是在存儲引擎層實現(xiàn)的，不同的存儲引擎對行級鎖的實現(xiàn)可能略有不同。行級鎖分為共享鎖和排他鎖。

   • 共享鎖（Shared Lock）：允許多個事務(wù)同時讀取同一行，但是不能進(jìn)行寫操作。如果一個事務(wù)持有共享鎖，其他事務(wù)也可以持有共享鎖。共享鎖之間不會互相阻塞。

   • 排他鎖（Exclusive Lock）：只允許一個事務(wù)進(jìn)行寫操作，其他事務(wù)不能進(jìn)行讀取或?qū)懭氩僮?。如果一個事務(wù)持有排他鎖，其他事務(wù)無法獲得共享鎖或排他鎖。排他鎖會阻塞其他事務(wù)的讀寫操作，因此需要慎重使用。

2.如何使用全局鎖

全局鎖（Global Lock）是 MySQL 中一種最為粗暴的鎖，可以鎖定整個 MySQL 實例，用于執(zhí)行全局操作時，比如備份整個數(shù)據(jù)庫。全局鎖會阻塞所有對數(shù)據(jù)庫的操作，因此在使用全局鎖時需要慎重考慮。

全局鎖可以通過執(zhí)行以下語句來獲得：

FLUSH TABLES WITH READ LOCK;

執(zhí)行該語句后，MySQL 將會阻塞所有對表的讀寫操作，直到當(dāng)前連接釋放鎖為止。注意，FLUSH TABLES WITH READ LOCK 只能獲得共享鎖（讀鎖），不支持排他鎖（寫鎖）。

3.如果要全庫只讀，為什么不使用set global readonly=true的方式？

1.在有些系統(tǒng)中，readonly的值會被用來做其他邏輯，比如判斷主備庫。所以修改global變量的方式影響太大。

2.在異常處理機(jī)制上有差異。如果執(zhí)行FTWRL命令之后由于客戶端發(fā)生異常斷開，那么MySQL會自動釋放這個全局鎖，整個庫回到可以正常更新的狀態(tài)。而將整個庫設(shè)置為readonly之后，如果客戶端發(fā)生異常，則數(shù)據(jù)庫就會一直保持readonly狀態(tài)，這樣會導(dǎo)致整個庫長時間處于不可寫狀態(tài)，風(fēng)險較高。

4.表級鎖和行級鎖有什么區(qū)別？

表級鎖和行級鎖是 MySQL 中最常用的兩種鎖類型，它們的區(qū)別在于鎖定的粒度不同，可以根據(jù)具體情況選擇使用不同的鎖類型。

1.表級鎖

表級鎖是鎖定整張表，通常在執(zhí)行大量寫操作時使用。表級鎖可以分為讀鎖（共享鎖）和寫鎖（排他鎖）。

讀鎖（共享鎖）：多個事務(wù)可以同時對同一張表進(jìn)行讀取操作，但是不能進(jìn)行寫入操作。在讀取操作期間，其他事務(wù)也可以獲取讀鎖，但是不能獲取寫鎖。

寫鎖（排他鎖）：只允許一個事務(wù)進(jìn)行寫入操作，其他事務(wù)不能進(jìn)行讀取或?qū)懭氩僮?。在寫入操作期間，其他事務(wù)不能獲取讀鎖或?qū)戞i，直到當(dāng)前事務(wù)釋放寫鎖為止。

表級鎖的優(yōu)點是鎖定粒度大，鎖的管理和維護(hù)成本低，容易控制。但是，鎖定整張表會導(dǎo)致其他事務(wù)等待鎖的時間變長，降低并發(fā)性能。因此，在執(zhí)行大量寫操作時使用表級鎖要慎重，需要考慮鎖的粒度和并發(fā)性能的平衡。

2.行級鎖

行級鎖是鎖定表中的某一行，通常在執(zhí)行大量讀操作時使用。行級鎖可以分為共享鎖和排他鎖，具體實現(xiàn)依賴于存儲引擎的實現(xiàn)。

共享鎖：多個事務(wù)可以同時讀取同一行數(shù)據(jù)，但是不能進(jìn)行寫操作。在讀取操作期間，其他事務(wù)也可以獲取共享鎖，但是不能獲取排他鎖。

排他鎖：只允許一個事務(wù)進(jìn)行寫入操作，其他事務(wù)不能進(jìn)行讀取或?qū)懭氩僮鳌Ｔ趯懭氩僮髌陂g，其他事務(wù)不能獲取共享鎖或排他鎖，直到當(dāng)前事務(wù)釋放排他鎖為止。

相對于表級鎖，行級鎖的優(yōu)點是鎖定粒度更細(xì)，可以減少鎖沖突的概率，提高并發(fā)性能。但是，行級鎖會帶來額外的開銷，包括鎖的管理和維護(hù)成本，因此需要權(quán)衡鎖定粒度和性能開銷，選擇適合的鎖類型。

需要注意的是，MySQL 在不同的存儲引擎上實現(xiàn)鎖的方式不同，比如 MyISAM 存儲引擎使用表級鎖，InnoDB 存儲引擎使用行級鎖和表級鎖的組合，因此在使用鎖時需要注意存儲引擎的不同實現(xiàn)。

5.行級鎖的使用有什么注意事項？

1.避免鎖定過多行

行級鎖的鎖定粒度比表級鎖要細(xì)，鎖的管理和維護(hù)成本也更高，如果鎖定了過多的行，可能會導(dǎo)致鎖沖突和性能問題。因此，在使用行級鎖時應(yīng)該盡量減少鎖定的行數(shù)，只鎖定必要的行，避免鎖的數(shù)量和時間過長。

2.盡量使用索引

行級鎖在鎖定某一行時，會對該行所在的索引加鎖。如果沒有使用索引，MySQL 將會對整張表進(jìn)行掃描，導(dǎo)致鎖定粒度變大，降低并發(fā)性能。因此，在使用行級鎖時，應(yīng)該盡量使用索引，提高鎖定粒度，減少鎖的數(shù)量和時間。

3.優(yōu)化事務(wù)的大小

事務(wù)的大小會直接影響鎖定的行數(shù)和時間，如果事務(wù)過大，將會導(dǎo)致鎖定的行數(shù)過多，增加鎖沖突和性能問題的概率。因此，在使用行級鎖時，應(yīng)該盡量優(yōu)化事務(wù)的大小，盡可能減小事務(wù)的范圍和時間，提高并發(fā)性能。

例如，有一個商品表 products，需要批量更新價格，如果事務(wù)過大，將會導(dǎo)致鎖定的行數(shù)過多，性能較差，可以將大事務(wù)分為多個小事務(wù)，例如：

-- 批量更新前半部分商品價格
BEGIN;
UPDATE products SET price = price * 0.9 WHERE id BETWEEN 1 AND 500;
COMMIT;-- 批量更新后半部分商品價格
BEGIN;
UPDATE products SET price = price * 0.9 WHERE id BETWEEN 501 AND 1000;
COMMIT;

4.使用鎖的超時機(jī)制

MySQL 支持鎖的超時機(jī)制，當(dāng)鎖定時間超過指定的時間時，將自動釋放鎖，避免鎖沖突和死鎖問題。在使用行級鎖時，應(yīng)該合理設(shè)置鎖的超時時間，避免長時間等待鎖導(dǎo)致性能問題。

例如，有一個賬戶表 account，需要轉(zhuǎn)賬操作，如果鎖定的時間過長，將會影響并發(fā)性能，可以使用鎖的超時機(jī)制來避免鎖定時間過長，例如：

BEGIN;
SELECT * FROM account WHERE id = 1 FOR UPDATE NOWAIT;
-- 更新賬戶表中 id=1 的記錄
COMMIT;

這里使用 NOWAIT 關(guān)鍵字來設(shè)置鎖的超時機(jī)制，如果獲取不到鎖，將立即返回錯誤，避免了鎖定時間過長。

需要注意的是，使用鎖的超時機(jī)制時，應(yīng)該避免死鎖的情況，如果出現(xiàn)死鎖，超時機(jī)制可能會誤判導(dǎo)致數(shù)據(jù)不一致。

6.InnoDB 有哪幾類行鎖？

實際上，InnoDB 行鎖定不僅僅是對索引數(shù)據(jù)頁上的記錄加鎖，而是對整個索引記錄（包括數(shù)據(jù)頁和索引頁）進(jìn)行加鎖。當(dāng)使用 InnoDB 表時，MySQL 提供了三種行級鎖定方式，分別是：

1. 記錄鎖（Record Lock）：也稱行鎖，只鎖定某個索引上的一行記錄，即對某個記錄加鎖。

2. 間隙鎖（Gap Lock）：鎖定索引記錄之間的間隙，但不包括記錄本身，鎖定某個范圍之前的間隙或之后的間隙，但不包括指定范圍的記錄本身。例如，使用 WHERE 子句查詢某個范圍內(nèi)的記錄時，如果使用間隙鎖定，將鎖定范圍之前或之后的間隙，避免其他事務(wù)插入相同范圍的記錄。

3. Next-Key 鎖（Next-Key Lock）：鎖定索引記錄和索引記錄之間的間隙，包括索引記錄本身和之前的間隙，但不包括之后的間隙。Next-Key 鎖包含了 Record Lock 和 Gap Lock，確保了同時避免幻讀和更新丟失。

InnoDB 默認(rèn)的隔離級別是 REPEATABLE-READ，行鎖默認(rèn)使用的是 Next-Key Lock。在 REPEATABLE-READ 隔離級別下，MySQL 會在讀取數(shù)據(jù)時鎖定所有讀取到的數(shù)據(jù)行（記錄鎖），同時鎖定所有查詢范圍之前的間隙（Gap Lock）。此外，MySQL 還會對每個查詢的結(jié)果集中的第一個記錄之前的間隙加上 Next-Key Lock，確保其他事務(wù)不會插入相同查詢范圍內(nèi)的記錄。這樣可以避免幻讀的問題。

需要注意的是，InnoDB 行級鎖定是基于索引實現(xiàn)的，如果沒有使用索引，MySQL 會自動添加一個隱藏的索引，然后再對該索引上的記錄進(jìn)行鎖定。同時，InnoDB 行鎖定是基于事務(wù)的，只有在事務(wù)隔離級別為可重復(fù)讀或串行化時才會生效。

7.什么是共享鎖和排他鎖

共享鎖和排他鎖是數(shù)據(jù)庫中常用的兩種鎖定方式，用于控制對共享資源的訪問和修改，保證數(shù)據(jù)的一致性和完整性。

共享鎖允許多個事務(wù)同時讀取同一份數(shù)據(jù)，但是只有一個事務(wù)可以對數(shù)據(jù)進(jìn)行修改。在獲取共享鎖之后，其他事務(wù)可以繼續(xù)獲取共享鎖，但是不能獲取排他鎖。共享鎖通常用于讀取數(shù)據(jù)時使用，可以防止并發(fā)修改數(shù)據(jù)時出現(xiàn)不一致的情況。

排他鎖只允許一個事務(wù)對數(shù)據(jù)進(jìn)行修改，其他事務(wù)需要等待該事務(wù)釋放鎖后才能進(jìn)行修改。在獲取排他鎖之后，其他事務(wù)不能獲取共享鎖和排他鎖。排他鎖通常用于修改數(shù)據(jù)時使用，可以避免并發(fā)修改數(shù)據(jù)時出現(xiàn)競爭的情況。

舉個例子來說，假設(shè)有一個銀行賬戶表，多個用戶需要對該表進(jìn)行讀取和修改。在讀取賬戶余額時，可以使用共享鎖，多個用戶可以同時讀取賬戶余額；在修改賬戶余額時，需要使用排他鎖，只有一個用戶可以對賬戶余額進(jìn)行修改。如果多個用戶同時修改賬戶余額，就可能會導(dǎo)致數(shù)據(jù)不一致或數(shù)據(jù)丟失的問題，因此需要使用排他鎖保證數(shù)據(jù)的完整性。

8.意向鎖有什么作用？

在多用戶環(huán)境下，事務(wù)之間可能會相互沖突，需要對訪問的數(shù)據(jù)行進(jìn)行加鎖以防止沖突。但是在一個事務(wù)中，如果需要對多個數(shù)據(jù)行進(jìn)行加鎖，那么需要先獲取這些數(shù)據(jù)行所在的數(shù)據(jù)頁上的鎖，然后再獲取對應(yīng)的行鎖，這樣就會產(chǎn)生很多額外的開銷，影響系統(tǒng)性能。

為了減少這種開銷，InnoDB使用意向鎖來幫助事務(wù)減少對鎖的獲取次數(shù)。意向鎖并不實際限制數(shù)據(jù)行的訪問，而是用來指示一個事務(wù)即將獲取的鎖的類型（共享鎖或排他鎖）。當(dāng)事務(wù)請求獲取一個數(shù)據(jù)行上的行級別鎖時，InnoDB會首先獲取該數(shù)據(jù)頁的意向鎖，以確保該數(shù)據(jù)頁上不會出現(xiàn)與該事務(wù)請求相沖突的其他鎖。

在 InnoDB 存儲引擎中，意向鎖分為意向共享鎖（Intention Shared Lock）和意向排他鎖（Intention Exclusive Lock）兩種。意向共享鎖表示事務(wù)需要在一個數(shù)據(jù)頁上獲取多個行共享鎖，而意向排他鎖表示事務(wù)需要在一個數(shù)據(jù)頁上獲取行排他鎖。

意向鎖是表級鎖，共有兩種：

• 意向共享鎖（Intention Shared Lock，IS 鎖）：事務(wù)有意向?qū)Ρ碇械哪承┯涗浖庸蚕礞i（S 鎖），加共享鎖前必須先取得該表的 IS 鎖。
• 意向排他鎖（Intention Exclusive Lock，IX 鎖）：事務(wù)有意向?qū)Ρ碇械哪承┯涗浖优潘i（X 鎖），加排他鎖之前必須先取得該表的 IX 鎖。

意向鎖并不是一個實際存在的鎖，它只是對一個事務(wù)請求所需的行級別鎖的指示。意向鎖是由數(shù)據(jù)庫自己維護(hù)的，用戶無法手動操作意向鎖。它的作用是幫助數(shù)據(jù)庫減少鎖競爭，提高并發(fā)性能。

當(dāng)一個事務(wù)需要對一個數(shù)據(jù)行加鎖時，InnoDB 引擎會先獲取該數(shù)據(jù)行所在的數(shù)據(jù)頁上的意向鎖，然后再獲取對應(yīng)的行級別鎖。這樣可以確保該數(shù)據(jù)頁上不會出現(xiàn)與該事務(wù)請求相沖突的其他鎖。

意向鎖之間是互相兼容的。

意向鎖和共享鎖和排它鎖互斥（這里指的是表級別的共享鎖和排他鎖，意向鎖不會與行級的共享鎖和排他鎖互斥）。

9.當(dāng)前讀和快照讀有什么區(qū)別？

當(dāng)前讀和快照讀的區(qū)別主要在于讀取的數(shù)據(jù)版本不同，以及讀取的方式和時間不同。

1.數(shù)據(jù)版本不同

• 當(dāng)前讀：讀取的是最新的數(shù)據(jù)版本。
• 快照讀：讀取的是事務(wù)開始時的數(shù)據(jù)版本，也稱為一致性讀。

2.取方式和時間不同

• 當(dāng)前讀：需要加鎖，保證讀取的數(shù)據(jù)是最新的，適用于修改、刪除等操作，會阻塞其他事務(wù)的寫操作，但不會阻塞讀操作。
• 快照讀：不需要加鎖，可以并發(fā)讀取數(shù)據(jù)，適用于查詢操作。快照讀的時間點是事務(wù)開始時，只能讀取到該時間點之前的數(shù)據(jù)版本。

只有在事務(wù)隔離級別 RC(讀取已提交) 和 RR（可重讀）下，InnoDB 才會使用一致性非鎖定讀：

• 在 RC 級別下，對于快照數(shù)據(jù)，一致性非鎖定讀總是讀取被鎖定行的最新一份快照數(shù)據(jù)。
• 在 RR 級別下，對于快照數(shù)據(jù)，一致性非鎖定讀總是讀取本事務(wù)開始時的行數(shù)據(jù)版本。

10.自增鎖有了解嗎？

自增鎖是 InnoDB 存儲引擎中的一種特殊的行級鎖，主要用于保證自增列的唯一性。在 InnoDB 存儲引擎中，自增列一般通過給自增列加一個獨占鎖來保證唯一性。這個獨占鎖就是自增鎖。

當(dāng)一個事務(wù)往一張表中插入一行數(shù)據(jù)時，如果這行數(shù)據(jù)的自增列值需要通過獲取自增鎖來實現(xiàn)自增，那么該事務(wù)會在該自增鎖上加一個排他鎖，然后獲取自增值并插入到新的行中，最后釋放鎖。其他事務(wù)在獲取自增值時會阻塞，直到持有自增鎖的事務(wù)釋放鎖。

自增鎖的作用是保證自增列的唯一性，避免出現(xiàn)重復(fù)的自增值。它的加鎖范圍是自增索引上的鎖，鎖定自增值的同時，也會鎖定自增值的上一個值，避免其他事務(wù)在插入數(shù)據(jù)時重復(fù)使用自增值。

需要注意的是，由于自增鎖的使用會造成事務(wù)的阻塞，因此在高并發(fā)的場景下，如果頻繁地往表中插入數(shù)據(jù)，就可能會出現(xiàn)自增鎖成為瓶頸的情況。在這種情況下，可以考慮使用非自增列，或者使用更高效的自增列實現(xiàn)方式，例如使用主鍵生成器來生成唯一的主鍵值。

11.如何處理死鎖問題？

在數(shù)據(jù)庫中，鎖是為了保證數(shù)據(jù)的一致性和完整性而引入的機(jī)制。但是，當(dāng)多個事務(wù)同時獲取鎖并且互相等待對方釋放鎖的時候，就會發(fā)生死鎖問題。這時候，事務(wù)將無法繼續(xù)執(zhí)行下去，也無法回滾或提交，只能被強制終止。

解決策略：

等待：直接進(jìn)入等待，直到超時。這個超時時間可以通過參數(shù)innodb_lock_wait_timeout來設(shè)置。

死鎖檢測：發(fā)起死鎖檢測，發(fā)現(xiàn)死鎖后，主動回滾死鎖鏈條中的某一個事務(wù)，讓其他事務(wù)得以繼續(xù)執(zhí)行。將參數(shù)innodb_deadlock_detect設(shè)置為on，表示開啟這個邏輯。

死鎖檢測缺點：每個新來的被堵住的線程，都要判斷會不會由于自己的加入導(dǎo)致了死鎖，這是一個時間復(fù)雜度是O(n)的操作。要耗費大量的CPU資源