MySql 三大知識點——索引、鎖、事務

1. 索引

索引，相似書籍的目錄，能夠根據目錄的某個頁碼當即找到對應的內容。

索引的優勢：1. 天生排序。2. 快速查找。
索引的缺點：1. 佔用空間。2. 下降更新表的速度。

注意點：小表使用全表掃描更快，中大表才使用索引。超級大表索引基本無效。

索引從實現上說，分紅 2 種：彙集索引和輔助索引（也叫二級索引或者非彙集索引）

從功能上說，分爲 6 種：普通索引，惟一索引，主鍵索引，複合索引，外鍵索引，全文索引。

詳細說說 6 種索引：

一、普通索引：最基本的索引，沒有任何約束。
二、惟一索引：與普通索引相似，但具備惟一性約束。
三、主鍵索引：特殊的惟一索引，不容許有空值。
四、複合索引：將多個列組合在一塊兒建立索引，能夠覆蓋多個列。
五、外鍵索引：只有InnoDB類型的表纔可使用外鍵索引，保證數據的一致性、完整性和實現級聯操做。
六、全文索引：MySQL 自帶的全文索引只能用於 InnoDB、MyISAM ，而且只能對英文進行全文檢索，通常使用全文索引引擎（ES，Solr）。

• 注意：主鍵就是惟一索引，可是惟一索引不必定是主鍵，惟一索引能夠爲空，可是空值只能有一個，主鍵不能爲空。

另外，InnoDB 經過主鍵聚簇數據，若是沒有定義主鍵且沒有定義彙集索引， MySql 會選擇一個惟一的非空索引代替，若是沒有這樣的索引，會隱式定義個 6 字節的主鍵做爲聚簇索引，用戶不能查看或訪問。

簡單點說：

1. 設置主鍵時，會自動生成一個惟一索引，若是以前沒有彙集索引，那麼主鍵就是彙集索引。
2. 沒有設置主鍵時，會選擇一個不爲空的惟一索引做爲彙集索引，若是尚未，那就生成一個隱式的 6 字節的索引。

MySql 將數據按照頁來存儲，默認一頁爲 16kb，當你在查詢時，不會只加載某一條數據，而是將這個數據所在的頁都加載到 pageCache 中，這個其實和 OS 的就近訪問原理相似。

MySql 的索引使用 B+ 樹結構。在說 B+ 樹以前，先說說 B 樹，B 樹是一個多路平衡查找樹，相較於普通的二叉樹，不會發生極度不平衡的情況，同時也是多路的。

B 樹的特色是：他會將數據也保存在非頁子節點。

看圖可知：

而這個特色會致使非頁子節點不能存儲大量的索引。

而 B+ Tree 就是針對這個對 B tree 作了優化。以下圖所示：

咱們看到，B+ Tree 將全部的 data 數據都保存到了葉子節點中，非也子節點只保存索引和指針。

咱們假設一個非頁子節點是 16kb，每一個索引，即主鍵是 bigint，即 8b，指針爲 8b。那麼每頁能存儲大約 1000 個索引（16kb/ 8b + 8b）.

而一顆 3 層的 B+樹可以存儲多少索引呢？以下圖：

大約可以存儲 10 億個索引。一般 B+ 樹的高度在 2-4 層，因爲 MySql 在運行時，根節點是常駐內存的，所以每次查找只須要大約 2 -3 次 IO。能夠說，B+ 樹的設計，就是根據機械磁盤的特性來進行設計的。

知道了索引的設計，咱們可以知道另一些信息：

1. MySql 的主鍵不能太大，若是使用 UUID 這種，將會浪費 B+ 樹的非葉子節點。
2. MySql 的主鍵最好是自增的，若是使用 UUID 這種，每次插入都會調整 B+樹，從而致使頁分裂，嚴重影響性能。

那麼，若是項目中使用了分庫分表，咱們一般都會須要一個主鍵進行 sharding，那怎麼辦呢？在實現上，咱們能夠保留自增主鍵，而邏輯主鍵用來做爲惟一索引便可。

2. 鎖機制

關於 Mysql 的鎖，各類概念就會噴涌而出，事實上，鎖有好幾種維度，咱們來解釋一下。

1. 類型維度

• 共享鎖（讀鎖 / S 鎖）

• 排它鎖（寫鎖 / X 鎖）

  類型細分：

  • 意向共享鎖
  • 意向排他（互斥）鎖

• 悲觀鎖（使用鎖，即 for update）

• 樂觀鎖（使用版本號字段，相似 CAS 機制，即用戶本身控制。缺點：併發很高的時候，多了不少無用的重試）

2. 鎖的粒度（粒度維度）

• 表鎖
• 頁鎖（Mysql BerkeleyDB 引擎）
• 行鎖（InnoDB）

3. 鎖的算法（算法維度）

• Record Lock（單行記錄）
• Gap Lock（間隙鎖，鎖定一個範圍，但不包含鎖定記錄）
• Next-Key Lock（Record Lock + Gap Lock，鎖定一個範圍，而且鎖定記錄自己， MySql 防止幻讀，就是使用此鎖實現）

4. 默認的讀操做，上鎖嗎？

• 默認是 MVCC 機制（「一致性非鎖定讀」）保證 RR 級別的隔離正確性，是不上鎖的。

能夠選擇手動上鎖：select xxxx for update (排他鎖); select xxxx lock in share mode(共享鎖)，稱之爲「一致性鎖定讀」。

使用鎖以後，就能在 RR 級別下，避免幻讀。固然，默認的 MVCC 讀，也能避免幻讀。

既然 RR 可以防止幻讀，那麼，SERIALIZABLE 有啥用呢？

防止丟失更新。例以下圖：

這個時候，咱們必須使用 SERIALIZABLE 級別進行串行讀取。

最後，行鎖的實現原理就是鎖住彙集索引，若是你查詢的時候，沒有正確地擊中索引，MySql 優化器將會拋棄行鎖，使用表鎖。

3. 事務

事務是數據庫永恆不變的話題， ACID：原子性，一致性，隔離性，持久性。

四個特性，最重要的就是一致性。而一致性由原子性，隔離性，持久性來保證。

• 原子性由 Undo log 保證。Undo Log 會保存每次變動以前的記錄，從而在發生錯誤時進行回滾。
• 隔離性由 MVCC 和 Lock 保證。這個後面說。
• 持久性由 Redo Log 保證。每次真正修改數據以前，都會將記錄寫到 Redo Log 中，只有 Redo Log 寫入成功，纔會真正的寫入到 B+ 樹中，若是提交以前斷電，就能夠經過 Redo Log 恢復記錄。

而後再說隔離性。

隔離級別：

1. 未提交讀（RU）
2. 已提交讀（RC）
3. 可重複讀（RR）
4. 串行化（serializable）

每一個級別都會解決不一樣的問題，一般是3 個問題：髒讀，不可重複讀，幻讀。一張經典的圖：

這裏有個注意點，關於幻讀，在數據庫規範裏，RR 級別會致使幻讀，可是，因爲 Mysql 的優化，MySql 的 RR 級別不會致使幻讀：在使用默認的 select 時，MySql 使用 MVCC 機制保證不會幻讀；你也可使用鎖，在使用鎖時，例如 for update（X 鎖），lock in share mode（S 鎖），MySql 會使用 Next-Key Lock 來保證不會發生幻讀。前者稱爲快照讀，後者稱爲當前讀。

原理剖析：

• RU 發生髒讀的緣由：RU 原理是對每一個更新語句的行記錄進行加鎖，而不是對整個事務進行加鎖，因此會發生髒讀。而 RC 和 RR 會對整個事務加鎖。
• RC 不能重複讀的緣由：RC 每次執行 SQL 語句都會生成一個新的 Read View，每次讀到的都是不一樣的。而 RR 的事務從始至終都是使用同一個 Read View。
• RR 不會發生幻讀的緣由： 上面說過了。

那 RR 和 Serializble 有什麼區別呢？答：丟失更新。本文關於鎖的部分已經提到。

MVCC 介紹：全稱多版本併發控制。

innoDB 每一個彙集索引都有 4 個隱藏字段，分別是主鍵（RowID），最近更改的事務 ID（MVCC 核心），Undo Log 的指針（隔離核心），索引刪除標記（當刪除時，不會當即刪除，而是打標記，而後異步刪除）；

本質上，MVCC 就是用 Undo Log 鏈表實現。

MVCC 的實現方式：事務以排它鎖的方式修改原始數據，把修改前的數據存放於 Undo Log，經過回滾指針與數據關聯，若是修改爲功，什麼都不作，若是修改失敗，則恢復 Undo Log 中的數據。

多說一句，一般咱們認爲 MVCC 是相似樂觀鎖的方式，即便用版本號，而實際上，innoDB 不是這麼實現的。固然，這不影響咱們使用 MySql。

 

閱讀原文

參考

https://mp.weixin.qq.com/s/XwC9n2Ik_DrfY-ERd99wqA

https://mp.weixin.qq.com/s/V9nuZ-TNSI_avMVbCd1T7Q

https://www.imooc.com/article/17290