本篇是講解對於資料庫知識的整理，當然，不只是需要知道這個方面的內容，還需要掌握其他方面的知識，我都根據自己的經歷來進行了整理，方便大家進行系統化的學習，只有多複習多研究，才能對技術有更好的掌握，才能拿到更好的offer。
下面是其他方面的知識點，歡迎大家進行瀏覽

Java基礎：(https://blog.csdn.net/Cs_hnu_scw/article/details/79635874)
資料結構：(https://blog.csdn.net/Cs_hnu_scw/article/details/79896717)
Web方向：(https://blog.csdn.net/Cs_hnu_scw/article/details/79896165)
作業系統：(https://blog.csdn.net/Cs_hnu_scw/article/details/79896500)
計算機網路：(https://blog.csdn.net/Cs_hnu_scw/article/details/79896621)
其他方面的知識：(https://blog.csdn.net/Cs_hnu_scw/article/details/79896876)
思維導圖github：(https://github.com/qq496616246/MindMapping.git)
 

1：如何定位查詢較慢的SQL語句？

（方法一：慢查詢日誌）MySQL通過慢查詢日誌定位那些執行效率較低的SQL 語句，用–log-slow-queries[=file_name]選項啟動時，mysqld 會寫一個包含所有執行時間超過long_query_time 秒的SQL語句的日誌檔案，通過檢視這個日誌檔案定位效率較低的SQL 。
1，slow_query_log
這個引數設定為ON，可以捕獲執行時間超過一定數值的SQL語句。
2，long_query_time
當SQL語句執行時間超過此數值時，就會被記錄到日誌中，建議設定為1或者更短。
3，slow_query_log_file
記錄日誌的檔名。
4，log_queries_not_using_indexes
這個引數設定為ON，可以捕獲到所有未使用索引的SQL語句，儘管這個SQL語句有可能執行得挺快
（1）使用方法
MySQL在Windows系統中的配置檔案一般是是my.ini找到[mysqld]下面加上
程式碼如下：
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
slow_query_log = 1
long_query_time = 2
（2） 檢視慢SQL日誌是否啟用
mysql> show variables like ‘log_slow_queries’;
±-----------------±------+
| Variable_name | Value |
±-----------------±------+
| log_slow_queries | ON |
±-----------------±------+
1 row in set (0.00 sec)
（3） 檢視執行慢於多少秒的SQL會記錄到日誌檔案中
mysql> show variables like ‘long_query_time’;
±----------------±------+
| Variable_name | Value |
±----------------±------+
| long_query_time | 1 |
±----------------±------+
1 row in set (0.00 sec)
這裡value=1， 表示1秒
（方法二：通過explanin關鍵字：用來分析SQL語句的執行狀態）
（方法三：通過profile關鍵字：用來分析SQL語句的執行詳細），可以通過下面的文章進行詳細瞭解，它們的使用；

2：資料庫的儲存過程的特點？

儲存過程優點：
1、儲存過程增強了SQL語言靈活性。儲存過程可以使用控制語句編寫，可以完成複雜的判斷和較複雜的運算，有很強的靈活性；
2、減少網路流量，降低了網路負載。儲存過程在資料庫伺服器端建立成功後，只需要呼叫該儲存過程即可，而傳統的做法是每次都將大量的SQL語句通過網路傳送至資料庫伺服器端然後再執行；
3、儲存過程只在創造時進行編譯，以後每次執行儲存過程都不需再重新編譯，而一般SQL語句每執行一次就編譯一次,所以使用儲存過程可提高資料庫執行速度。
4、系統管理員通過設定某一儲存過程的許可權實現對相應的資料的訪問許可權的限制，避免了非授權使用者對資料的訪問，保證了資料的安全。
可以參考：

3：資料庫的三級模式是什麼？

資料庫的三級模式結構是指：資料庫系統是由外模式、模式和內模式三級構成，如圖

1. 模式（Schema）
   模式也稱為：邏輯模式，它是DB中全體資料的邏輯結構和特徵的描述，是所有使用者的公共資料檢視。模式層是資料庫模式結構的中間層，既不涉及到資料的物理儲存細節和硬體環境，也與具體的應用程式、應用開發工具以及高階程式設計語言無關（C、C++、JAVA等）。
   模式就是資料庫資料在邏輯上的檢視，且一個數據庫只有一個模式。實際工作中，模式就等同於程式設計師建立一個具體的資料庫的全部操作，如：這是一個MySQL資料庫，有2張表，每個表的名字，屬性的名字、型別、取值範圍，主鍵，外來鍵，索引，其他完整性約束等等。
   DBMS提供模式描述語言（模式DDL）來嚴格地定義模式。
2. 外模式
   外模式也稱為：子模式(subschema)/使用者模式，它是資料庫使用者（應用程式設計師、終端使用者）能夠看到的使用的區域性資料的邏輯結構和特徵的描述，是資料庫的資料檢視，是與某一個應用有關的資料的邏輯表示。
   外模式通常是模式的子集。一個數據庫可以有多個外模式。同一個外模式可以為某一使用者的多個應用系統所使用，但一個應用系統只能使用一個外模式。
   外模式是保證資料庫安全性的一個有力措施。每個使用者只能看見和訪問所對應的外模式中的資料，資料庫中的其餘資料是不可見的。
   DBMS提供子模式描述語言（子模式DDL）來嚴格地定義子模式。
3. 內模式
   內模式也稱為：儲存模式(Storage schema)，一個數據庫只有一個內模式。它是資料庫物理結構和儲存方式的描述，是資料在資料庫內部的表示方式。如：記錄的儲存方式是堆儲存，還是按照某些屬性值的升（降）儲存，還是按照屬性值聚簇（cluster）儲存；索引按照什麼方式組織，是B+樹索引，還是hash索引等等。
   DBMS提供內模式描述語言（內模式DDL/儲存模式DDL）來嚴格定義內模式。
   二級映像功能和資料的獨立性
   資料庫的3級模式是對資料的3個抽象級別。它使得使用者能夠邏輯地抽象地處理資料，而不必再去關心資料在計算機中的具體表示方式與儲存方式。實際上，為了能夠實現在這3個抽象層次之間的聯絡和轉換，DBMS在這三級模式之間設計了兩層映像：
   外模式/模式映像
   模式/內模式映像
   這兩層映像保證了資料庫中的資料能夠具有較高的邏輯獨立性和物理獨立性。
   1. 外模式/模式映像
   由上可知：一個DB只有一個模式，但可以有多個外模式。
   所以，對於每一個外模式，資料庫系統都有一個外模式/模式映像，它定義了這個外模式與模式的對應關係。外模式的描述中通常包含了這些映像的定義。
   當模式改變時（增加新的關係、新的屬性、改變屬性的資料型別等），由資料庫管理員對各個外模式/模式映像作相應的改變，可以使得外模式保持不變。而又由於應用程式應該是依據外模式編寫的，從而應用程式不必修改，這就保證了資料與程式的邏輯獨立性。
   總結：外模式/模式映像保證了當模式改變時，外模式不用變 — 邏輯獨立性。
   2. 模式/內模式映像
   由上可知：一個DB只有一個模式，也只有一個內模式，所有模式/內模式映像是唯一的，它定義了資料全域性邏輯結構與儲存結構之間的對應關係。
   當資料庫的儲存結構改變時（例如選用了另一個儲存結構），由資料庫管理員對模式/內模式映像作出相應的改變，可以使得模式保持不變，從而應用程式也不必改變。這就保證了資料和程式的物理獨立性。
   總結：模式/內模式映像保證了當內模式改變時，模式不用變 — 物理獨立性。

4：資料庫備份和恢復的方法？

5：下面SQL語句執行的順序是什麼？

select foo,count(foo)from pokes where foo>10group by foo having count (*)>5 order by foo
答：FROM->WHERE->GROUP BY->HAVING->SELECT->ORDER BY

6：在mysql中，欄位型別中的char，varchar，blob，text的區別？

它們的儲存方式和資料的檢索方式都不一樣

1. char：儲存定長資料很方便（最多不可以超過255字元），CHAR欄位上的索引效率級高，必須在括號裡定義長度，可以有預設值，比如定義char(10)，那麼不論你儲存的資料是否達到了10個位元組，都要佔去10個位元組的空間（自動用空格填充），且在檢索的時候後面的空格會隱藏掉，所以檢索出來的資料需要記得用什麼trim之類的函式去過濾空格。
2. varchar：儲存變長資料（最多不可以超過65535位元組），但儲存效率沒有CHAR高，必須在括號裡定義長度，可以有預設值。儲存資料的時候，不進行空格自動填充，而且如果資料存在空格時，當值儲存和檢索時尾部的空格仍會保留。另外，varchar型別的實際長度是它的值的實際長度+1，這一個位元組用於儲存實際使用了多大的長度。
3. BLOB被視為二進位制字串,BLOB列沒有字符集，並且排序和比較基於列值位元組的數值值,在大多數方面，可以將BLOB列視為能夠足夠大的VARBINARY列
4. text：儲存可變長度的非Unicode資料，最大長度為2^31-1個字元。text列不能有預設值，儲存或檢索過程中，不存在大小寫轉換，後面如果指定長度，不會報錯誤，但是這個長度是不起作用的，意思就是你插入資料的時候，超過你指定的長度還是可以正常插入。
   結論：
   （1）經常變化的欄位用varchar；
   （2）知道固定長度的用char；
   （3）儘量用varchar；
   （4）超過255位元組的只能用varchar或者text；
   （5）能用varchar的地方不用text；
   （6）能夠用數字型別的欄位儘量選擇數字型別而不用字串型別的（電話號碼），這會降低查詢和連線的效能，並會增加儲存開銷。這是因為引擎在處理查詢和連接回逐個比較字串中每一個字元，而對於數字型而言只需要比較一次就夠；
   （7）如果是要儲存二進位制流的內容（比如圖片），那麼可以採取用Blob；

7：什麼情況下應該對欄位建立索引？

1. 經常查詢的欄位；
2. 唯一性強的欄位，比如像性別欄位，區分度不大，所以不適合建立；唯一性強的欄位，比如像性別欄位，區分度不大，所以不適合建立；
3. 出現在where條件查詢的欄位，因為如果不會出現在where欄位之後，那麼建立索引也就沒有必要了；出現在where條件查詢的欄位，因為如果不會出現在where欄位之後，那麼建立索引也就沒有必要了；
4. 不經常修改的欄位，因為對於經常修改的欄位，那麼還要進行索引的維護，這是需要消耗時間和空間；不經常修改的欄位，因為對於經常修改的欄位，那麼還要進行索引的維護，這是需要消耗時間和空間；
5. 不會出現null值的欄位；不會出現null值的欄位；

8：欄位存在索引但是會發現無效的情況有哪些？

1. 進行了模糊匹配，使用"%Like"
2. 使用了or查詢，兩端的欄位某個不存在索引
3. 進行了函式操作欄位，比如abs（）函式進行了函式操作欄位，比如abs（）函式
4. 對欄位進行了運算，比如使用！= 或者< ,>等對欄位進行了運算，比如使用！= 或者< ,>等
5. 對於Bolb和text欄位，只能使用字首索引對於Bolb和text欄位，只能使用字首索引
6. join條件欄位型別不一致的時候join條件欄位型別不一致的時候
7. 對於欄位出現null的情況，並且這種欄位是不適合建立索引對於欄位出現null的情況，並且這種欄位是不適合建立索引

9：資料庫中的內連線，左連線，右連線，全連線，交叉連線？

答：內連線：內連線查詢操作列出與連線條件匹配的資料行，它使用比較運算子比較被連線列的列值。(有下面三種)

1. 等值連線：在連線條件中使用等於號(=)運算子比較被連線列的列值，其查詢結果中列出被連線表中的所有列，包括其中的重複列。
2. 不等值連線：在連線條件使用除等於運算子以外的其它比較運算子比較被連線的列的列值。這些運算子包括>、>=、<=、<、!>、!<和<>。不等值連線：在連線條件使用除等於運算子以外的其它比較運算子比較被連線的列的列值。這些運算子包括>、>=、<=、<、!>、!<和<>。
3. 自然連線：在連線條件中使用等於(=)運算子比較被連線列的列值，但它使用選擇列表指出查詢結果集合中所包括的列，並刪除連線表中的重複列。自然連線：在連線條件中使用等於(=)運算子比較被連線列的列值，但它使用選擇列表指出查詢結果集合中所包括的列，並刪除連線表中的重複列。
4. 左聯接：是以左表為基準，將a.stuid = b.stuid的資料進行連線，然後將左表沒有的對應項顯示，右表的列為NULL左聯接：是以左表為基準，將a.stuid = b.stuid的資料進行連線，然後將左表沒有的對應項顯示，右表的列為NULL
5. 右連線：是以右表為基準，將a.stuid = b.stuid的資料進行連線，然以將右表沒有的對應項顯示，左表的列為NULL右連線：是以右表為基準，將a.stuid = b.stuid的資料進行連線，然以將右表沒有的對應項顯示，左表的列為NULL
6. 全連線：完整外部聯接返回左表和右表中的所有行。當某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結果集行包含基表的資料值；（注意：在mysql中是不支援這種方式的，而只能通過先左連線，然後使用union all 再與右連線的方式）
7. 全連線：完整外部聯接返回左表和右表中的所有行。當某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結果集行包含基表的資料值；（注意：在mysql中是不支援這種方式的，而只能通過先左連線，然後使用union all 再與右連線的方式）全連線：完整外部聯接返回左表和右表中的所有行。當某行在另一個表中沒有匹配行時，則另一個表的選擇列表列包含空值。如果表之間有匹配行，則整個結果集行包含基表的資料值；（注意：在mysql中是不支援這種方式的，而只能通過先左連線，然後使用union all 再與右連線的方式）
8. 交叉連線：交叉聯接返回左表中的所有行，左表中的每一行與右表中的所有行組合。交叉聯接也稱作笛卡爾積。交叉連線：交叉聯接返回左表中的所有行，左表中的每一行與右表中的所有行組合。交叉聯接也稱作笛卡爾積。
   具體的例子：https://www.cnblogs.com/zxlovenet/p/4005256.html
   

10：資料庫的安全性如何保證？

1. 設定使用者的許可權：保證非法使用者的非法侵入；
2. 定義檢視：通過這樣把不同許可權使用者所能看到的資料和操作的資料進行隔離；
3. 資料加密：保證資料的保密性；資料加密：保證資料的保密性；
4. 啟動事務管理和故障恢復：防止意外情況的發生，保證資料的一致性和完整性，主要的措施是日誌記錄和資料複製；啟動事務管理和故障恢復：防止意外情況的發生，保證資料的一致性和完整性，主要的措施是日誌記錄和資料複製；
5. 資料庫備份和恢復：防止資料非法丟失和意外情況發現，保證資料可進行一定恢復；資料庫備份和恢復：防止資料非法丟失和意外情況發現，保證資料可進行一定恢復；
6. 審計追蹤機制：主要是對於資料的更新，刪除操作進行日誌記錄，方便後續的審查；審計追蹤機制：主要是對於資料的更新，刪除操作進行日誌記錄，方便後續的審查；
7. 加強伺服器的安全：因為資料庫都是存放在伺服器中的，所以需要保證伺服器的安全；加強伺服器的安全：因為資料庫都是存放在伺服器中的，所以需要保證伺服器的安全；

11：資料庫中的正規化？

主要是分析第一正規化，第二正規化，第三正規化以及BCNF正規化
可以參考這篇不錯的文章：https://blog.csdn.net/w__yi/article/details/19934319
知識擴充套件：
BCNF： 在第三正規化的基礎上，資料庫表中如果不存在任何欄位對任一候選關鍵欄位的傳遞函式依賴則符合第三正規化。
（1）所有非主屬性對每一個碼都是完全函式依賴；
（2）所有的主屬性對於每一個不包含它的碼，也是完全函式依賴；
（3）沒有任何屬性完全函式依賴於非碼的任意一個組合。
R屬於3NF，不一定屬於BCNF，如果R屬於BCNF，一定屬於3NF。
例項分析：假設倉庫管理關係表為StorehouseManage(倉庫ID, 儲存物品ID, 管理員ID, 數量)，且有一個管理員只在一個倉庫工作；一個倉庫可以儲存多種物品。這個資料庫表中存在如下決定關係：
(倉庫ID, 儲存物品ID) →(管理員ID, 數量)
(管理員ID, 儲存物品ID) → (倉庫ID, 數量)
所以，(倉庫ID, 儲存物品ID)和(管理員ID, 儲存物品ID)都是StorehouseManage的候選關鍵字，表中的唯一非關鍵欄位為數量，它是符合第三正規化的。但是，由於存在如下決定關係：
(倉庫ID) → (管理員ID)
(管理員ID) → (倉庫ID)
即存在關鍵欄位決定關鍵欄位的情況，所以其不符合BCNF正規化

12：主從（mater-slave）資料庫是如何達到資料庫一致操作？

具體操作流程：

1. 在Slave 伺服器上執行sart slave命令開啟主從複製開關，開始進行主從複製。
2. 此時，Slave伺服器的IO執行緒會通過在master上已經授權的複製使用者許可權請求連線master伺服器，並請求從執行binlog日此時，Slave伺服器的IO執行緒會通過在master上已經授權的複製使用者許可權請求連線master伺服器，並請求從執行binlog日誌檔案的指定位置（日誌檔名和位置就是在配置主從複製服務時執行change master命令指定的）之後開始傳送binlog日誌內容
3. Master伺服器接收到來自Slave伺服器的IO執行緒的請求後，其上負責複製的IO執行緒會根據Slave伺服器的IO執行緒請求的資訊Master伺服器接收到來自Slave伺服器的IO執行緒的請求後，其上負責複製的IO執行緒會根據Slave伺服器的IO執行緒請求的資訊分批讀取指定binlog日誌檔案指定位置之後的binlog日誌資訊，然後返回給Slave端的IO執行緒。返回的資訊中除了binlog日誌內容外，還有在Master伺服器端記錄的IO執行緒。返回的資訊中除了binlog中的下一個指定更新位置。
4. 當Slave伺服器的IO執行緒獲取到Master伺服器上IO執行緒傳送的日誌內容、日誌檔案及位置點後，會將binlog日誌內容依次當Slave伺服器的IO執行緒獲取到Master伺服器上IO執行緒傳送的日誌內容、日誌檔案及位置點後，會將binlog日誌內容依次寫到Slave端自身的Relay Log（即中繼日誌）檔案（Mysql-relay-bin.xxx）的最末端，並將新的binlog檔名和位置記錄到master-info檔案中，以便下一次讀取master端新binlog日誌時能告訴Master伺服器從新binlog日誌的指定檔案及位置開始讀取新的binlog日誌內容
5. Slave伺服器端的SQL執行緒會實時檢測本地Relay Log 中IO執行緒新增的日誌內容，然後及時把Relay LOG 檔案中的內容解析Slave伺服器端的SQL執行緒會實時檢測本地Relay Log 中IO執行緒新增的日誌內容，然後及時把Relay LOG 檔案中的內容解析成sql語句，並在自身Slave伺服器上按解析SQL語句的位置順序執行應用這樣sql語句，並在relay-log.info中記錄當前應用中繼日誌的檔名和位置點
   主從複製條件
   1、開啟Binlog功能
   2、主庫要建立賬號
   3、從庫要配置master.info（CHANGE MASTER to…相當於配置密碼檔案和Master的相關資訊）
   4、start slave 開啟複製功能
   知識點（這個在流程中有說明）
   1.3個執行緒，主庫IO，從庫IO和SQL及作用
   2.master.info（從庫）作用
   3.relay-log 作用
   4.非同步複製
   5.binlog作用（如果需要級聯需要開啟Binlog）

13：說說聚集索引和非聚集索引的理解？

1. 聚集索引
   聚集索引表記錄的排列順序和索引的排列順序一致，所以查詢效率快，只要找到第一個索引值記錄，其餘就連續性的記錄在物理也一樣連續存放。葉子節點儲存真實的資料行，不再有另外單獨的資料頁。在一張表上只能建立一個聚集索引，因為真實資料的物理順序只能有一種，若一張表沒有聚集索引，則它被稱為堆集，這樣表的資料行無特定的順序，所有新行將被新增到表的末尾。聚集索引可以是一列（單索引的時候）或者是多列（組合索引的時候）。但是，聚集索引對應的缺點就是修改慢，因為為了保證表中記錄的物理和索引順序一致，在記錄插入的時候，會對資料頁重新排序。
2. 非聚集索引
   非聚集索引制定了表中記錄的邏輯順序，但是記錄的物理和索引不一定一致，兩種索引都採用B+樹結構，非聚集索引的葉子層並不和實際資料頁相重疊，而採用葉子層包含一個指向表中的記錄在資料頁中的指標方式。非聚集索引層次多，不會造成資料重排。
3. 例子對比兩種索引
   聚集索引就類似新華字典中的拼音排序索引，都是按順序進行，例如找到字典中的“愛”，就裡面順序執行找到“癌”。而非聚集索引則類似於筆畫排序，索引順序和物理順序並不是按順序存放的。還可以類比，聚集索引就是電話薄是根據字母順序進行排列，而非聚集索引可以類比為書的目錄，雖然頁的索引的在一起，但是索引帶有指標才是真正指向資料的儲存位置。
4. 非聚集索引和聚集索引的區別：
   （1）葉子節點並非資料節點
   （2）葉子節點為每一個真正的資料行儲存一個"鍵-指標"對
   （3）葉子節點中還儲存了一個指標偏移量，根據頁指標及指標偏移可以定位到具體的資料行
   （4）在除葉子節點外的其他索引節點，儲存的是類似內容，只不過是指向下一級索引頁

14：請說說對於分頁操作你是如何做的？

比如，我現在需要找到產品表中的第800000條資料後面的20條資料。
（1）直接通過limit start count分頁語句，形如 select * from product limit start, count
比如：select * from product limit 800000 ， 20
缺點：通過通過這樣的方法的話，當資料表的資料非常多的時候，效率非常慢
總結：
1：limit語句的查詢時間與起始記錄的位置成正比。start越大，速度越慢。
2：mysql的limit語句是很方便，但是對記錄很多的表並不適合直接使用。
（2）利用表的覆蓋索引來加速分頁查詢
我們都知道，利用了索引查詢的語句中如果只包含了那個索引列（覆蓋索引），那麼這種情況會查詢很快。
所以，有兩種方法進行優化。
方法一：通過id >= 的形式。
原因：因為，在每個表中，列表項id基本都是主鍵，所以，這是符合覆蓋索引查詢的加速優化的條件的。
SELECT * FROM product WHERE ID > =(select id from product limit 800000 ，1) limit 20
方法二：通過join操作
SELECT * FROM product a JOIN (select id from product limit 800000 , 20) b ON a.ID = b.id

15：剛性事務和柔性事務是什麼？

1. 剛性事務是指嚴格遵循ACID原則的事務, 例如單機環境下的資料庫事務.
2. 柔性事務是指遵循BASE理論的事務, 通常用在分散式環境中, 常見的實現方式有: 兩階段提交(2PC), TCC補償型提交, 基於訊息的非同步確保型, 最大努力通知型.
3. 通常對本地事務採用剛性事務, 分散式事務使用柔性事務.通常對本地事務採用剛性事務, 分散式事務使用柔性事務.

16：資料庫select語句的完整執行順序是什麼？（重要）

（1）from子句組裝來自不同資料來源的資料
（2）where子句基於指定的條件對記錄進行篩選
（3）group by 子句將資料劃分為多個分組
（4）使用聚集函式進行計算
（5）使用having子句篩選分組
（6）計算所有的表示式
（7）select的欄位
（8）使用order by 對結果集進行排序
（9）limit進行篩選對應的條目數量
以上每個步驟都會產生一個虛擬表，該虛擬表被用作下一個步驟的輸入，這些虛擬表對呼叫者（客戶端應用程式或者外部查詢）不可用。只有最後一步生成的表才會給呼叫者。如果沒有在查詢中指定某一個子句，將跳過相應的步驟。

17：Mysql資料庫架構中各個模組的作用是什麼？

1. 連線管理與安全驗證
   每個客戶端都會建立一個與伺服器連線的執行緒，伺服器會有一個執行緒池來管理這些連線，如果客戶端需要連線到mysql資料庫還需要進行驗證，包括使用者名稱，密碼，主機資訊等
2. 解析器
   解析器的作用主要是分析查詢語句，最終生成解析樹；首先解析器會對查詢語句的語法進行分析，分析語法是否有問題。還有解析器會查詢快取，如果在快取中有對應的語句，就返回查詢結果不進行接下來的優化執行操作。前提是快取中的資料沒有被修改，當然如果被修改了也會被清出快取。
3. 優化器
   優化器的作用主要是對查詢語句進行優化操作，包括選擇合適的索引，資料的讀取方式，包括獲取查詢的開銷資訊，統計資訊等，這也是為什麼圖中會有優化器指向儲存引擎的箭頭。個人感覺，因為又花錢需要通過儲存引擎獲取查詢的大致資料和統計資訊。
4. 執行器
   執行器包括執行查詢語句，返回查詢結果，生成執行計劃包括與儲存引擎的一些處理操作。

18：為什麼Innodb採用B+樹的結構的效率更好呢？

1. 通過B+樹的結構，可以使得樹的高度小，這樣進行查詢效率快通過B+樹的結構，可以使得樹的高度小，這樣進行查詢效率快
2. B+樹的儲存內容相比二叉樹，B樹來說更多，這樣就可以方便計算機在讀取B+的內容的時候可以預讀後續的部分內容，從而減少檔案的IO操作，來提高效率。