走進mysql基礎

前言

做爲後端猿的咱們，不出意外天天都會和mysql打交道。除了天天寫不膩的CURD語句，關於mysql咱們應該要了解它的那些基礎知識呢？

直入主題

簡單畫出mysql的邏輯架構圖？

接 入 層
-----------------------
     ⬆          ⬆      
     ⬇          ⬇    
    緩 存      解 析 器
                 ⬆      
                 ⬇
              優 化 器 
-----------------------

        引 擎

mysql常見的引擎有哪些，區別是什麼？

• InnoDB

  • 支持事務
  • 行鎖
  • 聚簇索引
  • 輔助索引(二級索引)索引存放的是主鍵

• MyISAM

  • 不支持事務
  • 表鎖
  • 崩潰沒法安全恢復
  • 非聚簇索引
  • 輔助索引(二級索引)索引存放的仍是實際數據的地址

• Memory

  • 基於內存
  • 表鎖
  • 字段長度固定，不支持blob,text, 即便指定vachar實際儲存也會轉爲char

• Archive

  • 只支持insert/select操做
  • 適合日誌等
• ...

什麼是事務的ACDI概念？

• A: Atomicity, 原子性,　一個事務的全部操做視爲一個總體，要不所有成功，要不所有失敗。
• C: Consistency, 一致性,　一個事務下的全部的數據狀態變動，只有事務提交成功才所有變動。
• D: Durability, 持久性,　一旦事務提交成功，產生的數據變動將永久保存在數據庫中。
• I: Isolation, 隔離性,　一個事務在提交以前對其餘事務不可見。

什麼是髒讀，幻讀，不可重複讀？

• 髒讀：讀取未提交事務的數據，數據可能被回滾，不符合隔離性的定義。
• 幻讀：一個事務批量讀取了一批數據時，另外一個事務提交了新的數據，當以前的事務再次讀取時，會產生幻影行。
• 不可重複讀：執行兩次相同的查詢，可能獲得不一樣的結果。

mysql事務的隔離級別有哪些？默認的隔離級別是什麼？

• 未提交讀：一個事務還未提交，另外一個事務就能夠讀取，這樣致使的後果，髒讀。
• 提交讀(又叫，不可重複讀)：一個事務未提交對其餘事務不可見，可是會產生幻讀和不可重複讀。
• 可重複讀(mysql默認隔離級別)：保證同一個事務下屢次讀取的結果一致，可是會產生幻讀。
• 可串行化：嚴格的串行阻塞，併發能力很差。

隔離級別	髒讀	不可重複讀	幻讀
Read Uncommitted	√	√	√
Read Committed	×	√	√
Repeatable Read	×	×	√
Serializable	×	×	×

什麼是MVCC？簡述MVCC的做用及原理？

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、大於、小於)爲止，及該部分索引有效。

InnoDB爲何不採用紅黑樹而採用B+樹做爲索引存放數據結構，並簡要畫出B+樹？(目前我我的的理解比較淺歡迎積極糾正～)

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

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

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

結語

後續持續修正和補充，若是有什麼寫的不對的地方歡迎你們積極指正，謝謝你們。

掃面下方二維碼關注個人技術公衆號，及時爲你們推送個人原創技術分享