推薦（免費(fèi)）：SQL

零、數(shù)據(jù)庫驅(qū)動(dòng)

• MySQL 驅(qū)動(dòng)在底層幫我們做了對(duì)數(shù)據(jù)庫的連接，只有建立了連接了，才能夠有后面的交互。

一、數(shù)據(jù)庫連接池

• 數(shù)據(jù)庫連接池有 Druid、C3P0、DBCP
• 采用連接池大大節(jié)省了不斷創(chuàng)建與銷毀線程的開銷，這就是有名的「池化」思想，不管是線程池還是 HTTP 連接池，都能看到它的身影

二、SQL 接口

• MySQL 中處理請求的線程在獲取到請求以后獲取 SQL 語句去交給 SQL 接口去處理。

三、查詢解析器

• 將 SQL 接口傳遞過來的 SQL 語句進(jìn)行解析，翻譯成 MySQL 自己能認(rèn)識(shí)的語言。

四、MySQL 查詢優(yōu)化器

• MySQL 會(huì)依據(jù)成本最小原則來選擇使用對(duì)應(yīng)的索引
• 成本 = IO 成本 + CPU 成本
• IO成本 ： 即從磁盤把數(shù)據(jù)加載到內(nèi)存的成本，默認(rèn)情況下，讀取數(shù)據(jù)頁的 IO 成本是 1，MySQL 是以頁的形式讀取數(shù)據(jù)的，即當(dāng)用到某個(gè)數(shù)據(jù)時(shí)，并不會(huì)只讀取這個(gè)數(shù)據(jù)，而會(huì)把這個(gè)數(shù)據(jù)相鄰的數(shù)據(jù)也一起讀到內(nèi)存中，這就是有名的程序局部性原理，所以 MySQL 每次會(huì)讀取一整頁，一頁的成本就是 1。所以 IO 的成本主要和頁的大小有關(guān)
• CPU 成本：將數(shù)據(jù)讀入內(nèi)存后，還要檢測數(shù)據(jù)是否滿足條件和排序等 CPU 操作的成本，顯然它與行數(shù)有關(guān)，默認(rèn)情況下，檢測記錄的成本是 0.2。
• MySQL 優(yōu)化器 會(huì)計(jì)算 「IO 成本 + CPU」 成本最小的那個(gè)索引來執(zhí)行

五、存儲(chǔ)引擎

• 查詢優(yōu)化器會(huì)調(diào)用存儲(chǔ)引擎的接口，去執(zhí)行 SQL，也就是說真正執(zhí)行 SQL 的動(dòng)作是在存儲(chǔ)引擎中完成的。
• 數(shù)據(jù)是被存放在內(nèi)存或者是磁盤中的
• 每次在執(zhí)行 SQL 的時(shí)候都會(huì)將其數(shù)據(jù)加載到內(nèi)存中，這塊內(nèi)存就是 InnoDB 中一個(gè)非常重要的組件：緩沖池 Buffer Pool

六、執(zhí)行器

• 執(zhí)行器最終最根據(jù)一系列的執(zhí)行計(jì)劃去調(diào)用存儲(chǔ)引擎的接口去完成 SQL 的執(zhí)行

七、Buffer Pool

• Buffer Pool （緩沖池）是 InnoDB 存儲(chǔ)引擎中非常重要的內(nèi)存結(jié)構(gòu)，起到一個(gè)緩存的作用
• Buffer Pool 就是我們第一次在查詢的時(shí)候會(huì)將查詢的結(jié)果存到 Buffer Pool 中，這樣后面再有請求的時(shí)候就會(huì)先從緩沖池中去查詢，如果沒有再去磁盤中查找，然后在放到 Buffer Pool 中
• Buffer Pool中被使用的數(shù)據(jù)回被加鎖。
  

八、三個(gè)日志文件

1、undo 日志文件：記錄數(shù)據(jù)被修改前的樣子

• 作用：利用undo 日志文件完成事務(wù)回滾

2、redo 日志文件：記錄數(shù)據(jù)被修改后的樣子

• redo 記錄的是數(shù)據(jù)修改之后的值，不管事務(wù)是否提交都會(huì)記錄下來
• MySQL 為了提高效率，所以將這些操作都先放在內(nèi)存中去完成，更新后的數(shù)據(jù)會(huì)記錄在 redo log buffer 中，然后會(huì)在某個(gè)時(shí)機(jī)將其持久化到磁盤中。
  

3、bin log 日志文件： 記錄整個(gè)操作過程

bin log 記錄的是整個(gè)操作記錄（這個(gè)對(duì)于主從復(fù)制具有非常重要的意義）