文章目錄

MySQL數據庫之索引

索引之左匹配原則

這是最近準備春招復習數據庫部分總結到的一些數據庫方面比較重點的部分。
這是第一部分，主要是對於數據庫中索引、存儲引擎、三大範式的總結整合一些網上的博客，和自己過去做的一些筆記。
下一篇**MySQL數據庫學習（二）**將是對於MySQL的事務與隔離級別，以及MySQL的鎖機制和日誌模塊的一些總結

MySQL的基本邏輯架構圖：

連接器：驗證客戶端權限，建立和斷開MySQL連接
分析器：進行SQL語句的語法分析
優化器：選擇索引，生成具體的SQL語句執行計劃
執行器：操作存儲引擎，執行SQL，返回執行結果
存儲引擎層：各個不同的存儲引擎都提供了一些讀寫接口來操作數據庫

關係型數據庫通常的整體架構：

MySQL數據庫之索引

索引概述

索引是對數據庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問數據庫表中的特定信息，就像一本書的目錄一樣，可以加快查詢速度，避免全表掃描

什麼樣的信息可以成爲索引？

主鍵，唯一鍵以及普通鍵等

經常需要作爲條件查詢的列上適合創建索引，並且該列上也必須有一定的區分度。創建索引需要維護，在插入數據的時候會重新維護各個索引樹（數據頁的分裂與合併），對性能造成影響。

優化索引之底層結構

二叉查找樹結構

對半搜索，時間複雜度爲O(logn)
缺點是，頻繁的插入刪除操作可能使二叉樹變成線性的，如下：
此時時間複雜度爲O(n)，檢索深度每增加一個深度，就會增加一次I/O，成本開銷會增大很多

B樹結構

B樹的特徵：

根節點至少包含兩個孩子

樹中每個結點最多含有m個孩子(m >= 2)

除了根節點和葉結點外，其他每個結點至少含有ceil(m/2)個孩子，ceil爲向上取整

所有葉子結點位於同一層（高度相同）

假設每個非終端結點中包含有n個關鍵字信息，其中

Ki(i = 1…n)爲關鍵字，且按順序升序排列

關鍵字的個數n必須滿足：[ceil(m / 2) - 1] <= n <= m - 1

非葉子結點的指針P[1],P[2],…,P[M];其中K[1]指向關鍵字小於K[1]的子樹，P[M - 1] 指向關鍵字大於K[M - 1]的子樹，其它P[i]指向關鍵字屬於(K[i-1], K[i])的子樹，比如看圖中關鍵字值爲8的這個結點，P1所對應的這個子樹，其值均小於8

查找效率爲O(logn)，與二叉查找樹一樣，同時因爲B-tree的這些上述特徵，在增刪改動數據時，根據一些策略，其結構可以保持，不會變爲線性。

B+樹結構（優於B樹）

B+樹是B樹的變體，其基本的定義與B樹相同,除了：

非葉子結點的子樹指針與關鍵字個數相同（所以相對於B樹，B+樹能夠存儲更多的關鍵字）

非葉子結點的子樹指針P[i]，指向關鍵字值**[K[i], K[i+1])**的子樹，注意區間爲左開右閉。

非葉子結點僅僅用來索引，數據都保存在葉子結點中（B+樹所有的檢索都是從根部開始，檢索到葉子結點才能結束，而且非葉子結點不存儲數據的話就能存儲更多關鍵字）

B+樹相對於B樹更矮

所有葉子結點均有一個鏈指針指向下一個葉子節點

綜合上面的，B+Tree更適合用來做存儲索引：

B+Tree的特點使得磁盤I/O代價更低，B+樹的內部結點並沒有指向關鍵字具體信息的指針，因此其內部結點相對B 樹更小，同樣空間可以讀入更多的節點，所以B+樹的磁盤讀寫代價更低
B+Tree的查詢效率更加穩定（查詢路徑均爲從根結點到葉子結點，查詢效率均爲O(logn)）
B+Tree更有利於對數據庫的掃描（只需要遍歷葉子結點就可以進行範圍查詢）

Hash結構

其查詢效率高於B+Tree，只需經過一次定位，就可以查詢到對應數據區
但是其也存在一些弊端，因而不能成爲數據庫的主流索引的扛把子：

僅僅能滿足 “=” , “IN”，不能使用範圍查詢
無法被用來避免數據的排序操作
不能利用部分索引鍵查詢，B+Tree可以利用組合索引中的部分索引查詢
不能避免表掃描
因爲Hash值是經過一定的算法得到的，所以存在相同的情況，當遇到大量Hash值相等的情況後性能不一定比B-Tree索引要高

位圖索引Bit-Map

使用的數據庫較少，比較主流的是Oracle數據庫
感興趣的小夥伴可以自己瞭解瞭解哈

索引之調優SQL

密集索引與稀疏索引

密集索引文件中的每個搜索碼值都對應一個索引值
稀疏索引文件只爲索引碼的某些值建立索引項
衆所周知，當前兩種主流的數據庫引爲MyISAM和InnoDB(下一部分會有二者的對比介紹)
在MyISAM存儲引擎中的索引均爲稀疏索引，InnoDB中有且僅有一個密集索引
InnoDB中密集索引的具體規則：
若一個主鍵被定義，該主鍵作爲密集索引
若沒有主鍵被定義，該表的第一個唯一非空索引就作爲密集索引
若不滿足以上條件，InnoDB內部會生成一個隱藏主鍵（密集索引）
非主鍵索引存儲相關的鍵位和其對應的主鍵值，包含兩次查找

聚簇索引和非聚簇索引

聚簇索引

聚簇索引也稱爲主鍵索引，其索引樹的葉子節點中存的是整行數據，表中行的物理順序與鍵值的邏輯（索引）順序相同。一個表只能包含一個聚集索引。因爲索引（目錄）只能按照一種方法進行排序。

非聚簇索引

非聚簇索引（普通索引）的葉子節點內容是主鍵的值。在 InnoDB 裏，非主鍵索引也被稱爲二級索引（secondary index）。

如果語句是 select * from User where id=3，即主鍵查詢方式，則只需要搜索主鍵索引樹。
如果語句是 select * from User where uid=23，即普通索引查詢方式，則需要先搜索普通索引樹，得到其對應的主鍵值爲 3，再到主鍵索引樹搜索一次。這個過程稱爲回表。

說道這裏，在InnoDB中，聚簇索引是密集索引；非聚簇索引是稀疏索引。

覆蓋索引

如果在普通索引樹上的查詢已經直接提供了結果，不需要回表操作，這樣的普通索引叫做覆蓋索引。覆蓋索引的使用可以顯著提高查詢效率，是常見的MySQL性能優化手段。

索引之左匹配原則

在聯合索引的情況下，不需要索引的全部定義，只要滿足最左前綴，就可以利用索引來加快查詢速度。這個最左前綴可以是聯合索引的最左 N 個字段，也可以是字符串索引的最左 M 個字符。最左前綴原則的利用也可以顯著提高查詢效率，是常見的MySQL性能優化手段。

數據庫三大範式

第一範式：1NF 原子性，數據不可再分，且這個單一屬性是由基本的數據類型所構成的
第二範式：2NF 唯一性使得每一行數據具有唯一性，並消除數據之間的部分依賴

依賴：依賴，就是在一個表中，其中某個字段的值B可以由另一個字段值A來決定

完全依賴：主鍵可能由多個屬性構成，完全依賴要求不允許存在非空主屬性依賴於主鍵中的某一部分屬性

若存在部分依賴，則將發生部分依賴的這一組屬性單獨新建一個實體，並且在舊實體中用外鍵於新實體關聯，且新實體與舊實體爲一對多的關係。

第三範式：3NF 實體中的屬性不能是其他實體中的非主屬性。因爲這樣會出現冗餘。

實體如果一個實體中出現了其它實體的非主屬性，可以將這兩個實體用外鍵關聯，而不是將另一張表的非主屬性直接寫在當前表中。

MySQL數據庫之存儲引擎

存儲引擎分類及特點

MySQL中最常見的存儲引擎有InnoDB和MyISAM，它們的主要區別如下：

MyISAM不支持事務；InnoDB是事務類型的存儲引擎。
MyISAM只支持表級鎖；InnoDB支持行級鎖和表級鎖，默認爲行級鎖。
MyISAM引擎不支持外鍵；InnoDB支持外鍵。
對於count(*)查詢來說MyISAM更有優勢，因爲其保存了行數。
InnoDB是爲處理巨大數據量時的最大性能設計的存儲引擎。
MyISAM支持全文索引（FULLTEXT）；InnoDB不支持。

最主要的區別就是MyISAM表不支持事務、不支持行級鎖、不支持外鍵。 InnoDB表支持事務、支持行級鎖、支持外鍵。

除了上述的那些存儲引擎之外，在數據庫中（不是MySQL）還有其他的存儲引擎，如MRG_MYISAM，Archive，Ndb cluster等。
在面試中常見的考察存儲引擎還有Memory，使用Memory作爲存儲引擎的表也可以叫做內存表，將數據存儲在了內存中，所以適合做臨時表來使用，在索引結構上支持B+樹索引和Hash索引。

如何更改或設置存儲引擎

直接隨意空降鏈接一枚，Google一下很多的，也感謝這位老哥…
https://blog.csdn.net/qq_36294875/article/details/81775274

MySQL數據庫學習（一）------MySQL索引+數據庫設計三大範式+存儲引擎