久久高清性色生活片,A视频免费观看,少妇aB又爽又紧无码网站

背景

數據庫的鎖是在多線程高并發的情況下用來保證數據穩定性和一致性的一種機制。MySQL 根據底層存儲引擎的不同，鎖的支持粒度和實現機制也不同。MyISAM 只支持表鎖，InnoDB 支持行鎖和表鎖。目前 MySQL 默認的存儲引擎是 InnoDB，這里主要介紹 InnoDB 的鎖。

InnoDB 存儲引擎

使用 InnoDB 的兩大優點：一是支持事務；二是支持行鎖。

MySQL 的事務

在高并發的情況下事務的并發處理會帶來幾個問題

臟讀：指在事務 A 處理過程里讀取到了事務 B 未提交的事務中的數據。比如在轉賬的例子中：小 A 開了一個事務給小 B 轉了1000 塊，還沒提交事務的時候就跟小 B 說，錢已經到賬了。這個時候小 B 去看了一下余額，發現果真到賬了（然后就開開心心刷抖音去了），這個時候小 A 回滾了事務，把 1000 塊又搞回去了。小 B 刷完抖音再去看下余額，發現錢又不見了。
不可重復讀：指在一個事務執行的過程中多次查詢某一數據的時候結果不一致的現象，由于在執行的過程中被另一個事務修改了這個數據并提交了事務。比如：事務 A 第一次讀小明的年齡是 18 歲，此時事務 B 將小明的年齡改成了 20 并提交了，這個時候事務 A 再次讀取小明的年齡發現是 20，這就是同一條數據不可重復讀。
幻讀：幻讀通常指的是對一批數據的操作完成后，有其他事務又插入了滿足條件的數據導致的現象。比如：事務 A 將數據庫性別為男的狀態都改成1 表示有錢人，這個時候事務 B 又插入了一條狀態為 0 沒錢人的記錄，這個時候，用戶再查看剛剛修改的數據時就會發現還有一行沒有修改，這就出現了幻讀。幻讀往往針對 insert 操作，臟讀和不可重復讀針對 select 操作。

由于高并發事務帶來這幾個問題，所以就產生了事務的隔離級別

Read uncommitted (讀未提交)：最低級別，任何情況都無法保證。
Read committed (讀已提交)：可避免臟讀的發生。
Repeatable read (可重復讀)：可避免臟讀、不可重復讀的發生。
Serializable (串行化)：可避免臟讀、不可重復讀、幻讀的發生。

InnoDB 常見的幾種鎖機制

共享鎖和獨占鎖（Shared and Exclusive Locks），InnoDB 通過共享鎖和獨占所兩種方式實現了標準的行鎖。共享鎖（S 鎖）：允許事務獲得鎖后去讀數據，獨占鎖（X 鎖）：允許事務獲得鎖后去更新或刪除數據。一個事務獲取的共享鎖 S 后，允許其他事務獲取 S 鎖，此時兩個事務都持有共享鎖 S，但是不允許其他事務獲取 X 鎖。如果一個事務獲取的獨占鎖（X），則不允許其他事務獲取 S 或者 X 鎖，必須等到該事務釋放鎖后才可以獲取到。大家可以通過下面的 SQL 感受下。

# T1

START TRANSACTION WITH CONSISTENT SNAPSHOT;

SELECT * FROM category WHERE category_no = 2 lock in SHARE mode; //共享鎖

SELECT * FROM category WHERE category_no = 2 for UPDATE; //獨占鎖

COMMIT;

# T2

START TRANSACTION WITH CONSISTENT SNAPSHOT;

SELECT * FROM category WHERE category_no = 2 lock in SHARE mode; //共享鎖

UPDATE category set category_name = '動漫' WHERE category_no = 2; //獨占鎖

COMMIT;

意向鎖（Intention Locks），上面說過 InnoDB 支持行鎖和表鎖，意向鎖是一種表級鎖，用來指示接下來的一個事務將要獲取的是什么類型的鎖（共享還是獨占）。意向鎖分為意向共享鎖（IS）和意向獨占鎖（IX），依次表示接下來一個事務將會獲得共享鎖或者獨占鎖。意向鎖不需要顯示的獲取，在我們獲取共享鎖或者獨占鎖的時候會自動的獲取，意思也就是說，如果要獲取共享鎖或者獨占鎖，則一定是先獲取到了意向共享鎖或者意向獨占鎖。意向鎖不會鎖住任何東西，除非有進行全表請求的操作，否則不會鎖住任何數據。存在的意義只是用來表示有事務正在鎖某一行的數據，或者將要鎖某一行的數據。原文：Intention locks are table-level locks that indicate which type of lock (shared or exclusive) a transaction requires later for a row in a table.
記錄鎖（record Locks），鎖住某一行，如果表存在索引，那么記錄鎖是鎖在索引上的，如果表沒有索引，那么 InnoDB 會創建一個隱藏的聚簇索引加鎖。所以我們在進行查詢的時候盡量采用索引進行查詢，這樣可以降低鎖的沖突。
間隙鎖（Gap Locks），間隙鎖是一種記錄行與記錄行之間存在空隙或在第一行記錄之前或最后一行記錄之后產生的鎖。間隙鎖可能占據的單行，多行或者是空記錄。通常的情況是我們采用范圍查找的時候，比如在學生成績管理系統中，如果此時有學生成績 60，72，80，95，一個老師要查下成績大于 72 的所有同學的信息，采用的語句是 select * from student where grade > 72 for update，這個時候 InnoDB 鎖住的不僅是 80，95，而是所有在 72-80，80-95，以及 95 以上的所有記錄。為什么會這樣呢？實際上是因為如果不鎖住這些行，那么如果另一個事務在此時插入了一條分數大于 72 的記錄，那會導致第一次的事務兩次查詢的結果不一樣，出現了幻讀。所以為了在滿足事務隔離級別的情況下需要鎖住所有滿足條件的行。
Next-Key Locks，NK 是一種記錄鎖和間隙鎖的組合鎖。是 3 和 4 的組合形式，既鎖住行也鎖住間隙。并且采用的左開右閉的原則。InnoDB 對于查詢都是采用這種鎖的。

舉個例子


CREATE TABLE `a` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `uid` int(10) unsigned DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_uid` (`uid`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

INSERT INTO `a`(uid) VALUES (1);
INSERT INTO `a`(uid) VALUES (2);
INSERT INTO `a`(uid) VALUES (3);
INSERT INTO `a`(uid) VALUES (6);
INSERT INTO `a`(uid) VALUES (10);

# T1
START TRANSACTION WITH CONSISTENT SNAPSHOT; //1

SELECT * FROM a WHERE uid = 6 for UPDATE; //2

COMMIT;  //5


# T2
START TRANSACTION WITH CONSISTENT SNAPSHOT;  //3

INSERT INto a(uid) VALUES(11);
INSERT INto a(uid) VALUES(5);  //4
INSERT INto a(uid) VALUES(7);
INSERT INto a(uid) VALUES(8);
INSERT INto a(uid) VALUES(9);

SELECT * FROM a WHERE uid = 6 for UPDATE;

COMMIT;

ROLLBACK;

按照上面 1，2，3，4 的順序執行會發現第 4 步被阻塞了，必須執行完第 5 步后才能插入成功。這里我們會很奇怪明明鎖住的是uid=6 的這一行，為什么不能插入 5 呢？原因就是這里采用了 next-key 的算法，鎖住的是（3,10）整個區間。感興趣的可以試一下。