摘要：持久性一旦事務提交成功，產生的數據變更將永久保存在數據庫中。不可重復讀執行兩次相同的查詢，可能得到不同的結果。可串行化嚴格的串行阻塞，并發能力不好。數據時記錄刪除時間為當前事務版本號。非聚簇索引樹的葉子節點存放實際數據的地址。

作為后端猿的我們，不出意外每天都會和mysql打交道。除了每天寫不膩的CURD語句，關于mysql我們應該要了解它的那些基礎知識呢？

       接 入 層
-----------------------
     ?          ?      
     ?          ?    
    緩 存      解 析 器
                 ?      
                 ?
              優 化 器 
-----------------------

        引 擎

InnoDB

支持事務

行鎖

聚簇索引

輔助索引(二級索引)索引存放的是主鍵

MyISAM

不支持事務

表鎖

崩潰無法安全恢復

非聚簇索引

輔助索引(二級索引)索引存放的還是實際數據的地址

Memory

基于內存

表鎖

字段長度固定，不支持blob,text, 即使指定vachar實際儲存也會轉為char

Archive

只支持insert/select操作

適合日志等

...

A: Atomicity, 原子性,　一個事務的所有操作視為一個整體，要不全部成功，要不全部失敗。

C: Consistency, 一致性,　一個事務下的所有的數據狀態變更，只有事務提交成功才全部變更。

D: Durability, 持久性,　一旦事務提交成功，產生的數據變更將永久保存在數據庫中。

I: Isolation, 隔離性,　一個事務在提交之前對其他事務不可見。

臟讀：讀取未提交事務的數據，數據可能被回滾，不符合隔離性的定義。

幻讀：一個事務批量讀取了一批數據時，另一個事務提交了新的數據，當之前的事務再次讀取時，會產生幻影行。

不可重復讀：執行兩次相同的查詢，可能得到不同的結果。

未提交讀：一個事務還未提交，另一個事務就可以讀取，這樣導致的后果，臟讀。

提交讀(又叫，不可重復讀)：一個事務未提交對其他事務不可見，但是會產生幻讀和不可重復讀。

可重復讀(mysql默認隔離級別)：保證同一個事務下多次讀取的結果一致，但是會產生幻讀。

可串行化：嚴格的串行阻塞，并發能力不好。

MVCC：Multi Version Concurrency Control,　多版本并發控制，mysql防止幻讀的一種技術手段。每行數據存在間隙行，間隙行存放該行數據的創建時間，刪除時間，這里的時間實際是事務的版本號。當，

select數據時：只查詢創建時間小于等于當前事務版本號 -> 當前事務或當前事務之前插入的行，刪除時間大于當前版本號的行 -> 當前事務版本前未被刪除的行。

update數據時：在原有行a的基礎上復制行a",行a的刪除時間設置為當前的事務版本號，行a"的創建時間設置為當前的事務版本號。

insert數據時：記錄創建時間為當前事務版本號。

delete數據時：記錄刪除時間為當前事務版本號。

死鎖產生的原因是兩個事務互相等待對方釋放，產生了循環依賴，mysql采用了死鎖檢測(檢測到循環依賴返回錯誤)和死鎖超時(超時回滾持有行鎖最少的事務)的方式盡可能去避免死鎖。例如：

行鎖：

UPDATE `table_demo` SET `a` = "test" WHERE `b` = "lalala";
UPDATE `table_demo` SET `b` = "test" WHERE `a` = "lalala";

UPDATE `table_demo` SET `b` = "test" WHERE `a` = "lalala";
UPDATE `table_demo` SET `a` = "test" WHERE `b` = "lalala";

聚簇索引：InnoDB, B+樹的葉子節點存放實際數據。

非聚簇索引：MyISAM, B+樹的葉子節點存放實際數據的地址。

覆蓋索引：要查詢的行被索引覆蓋，從索引中可以直接讀取，不需要回表查詢。例如：

CREATE TABLE `demo_table`(
    `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT "自增ID",
    `username` char(32) NOT NULL DEFAULT "" COMMENT "用戶名",
    `password` char(32) NOT NULL DEFAULT "" COMMENT "密碼",
    PRIMARY KEY (`id`),
    KEY `idx_username` (`username`)
)ENGINE=InnoDB DEFAULT CHARSET=UTF8;

explain select `username` from `demo_table` where `username` = "demo";
+----+-------------+------------+------+---------------+--------------+---------+-------+------+--------------------------+
| id | select_type | table      | type | possible_keys | key          | key_len | ref   | rows | Extra                    |
+----+-------------+------------+------+---------------+--------------+---------+-------+------+--------------------------+
|  1 | SIMPLE      | demo_table | ref  | idx_username  | idx_username | 96      | const |    1 | Using where; Using index |
+----+-------------+------------+------+---------------+--------------+---------+-------+------+--------------------------+

Extra里的Using index就是使用了覆蓋索引的意思。

個人目前理解：例如使用聯合索引，從左向右依次匹配，未匹配到索引字段或第一個范圍查找(between、like、大于、小于)為止，及該部分索引有效。

紅黑樹本質是二叉樹，每個節點最多擁有兩個子節點，所以紅黑樹的深度較深。

B樹每個節點最多可以有n個子節點，根節點常駐內存且每個節點剛好申請１個頁的大小，假如每個節點擁有100個子節點，那百萬級的數據我們基本上只需要深度是3就可以存下 => 100^3，這樣就減少的io次數(一個節點的大小通常為磁盤一個頁的大小)。

又有“局部性原理”(一旦一個數據被查詢，那么它附近的數據可能也會需要被查詢)，其次B+樹的葉子節點構成一個鏈表，這樣我們就可以很容易的查詢出一段范圍的數據，其次B+樹的根節點和內部節點只存放該索引下一個子節點的位置的指針，數據只存放在葉子節點里，這樣非葉子節點就可以有更多的空間存放索引的位置，索引的范圍就可以盡可能的大，從而樹的深度就可能的小。

后續持續修正和補充，如果有什么寫的不對的地方歡迎大家積極指正，謝謝大家。

掃面下方二維碼關注我的技術公眾號，及時為大家推送我的原創技術分享