您好,登錄后才能下訂單哦!
這篇文章主要介紹執(zhí)行一句SQL的情況有哪些,文中介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們一定要看完!
零、數(shù)據(jù)庫(kù)驅(qū)動(dòng)
MySQL 驅(qū)動(dòng)在底層幫我們做了對(duì)數(shù)據(jù)庫(kù)的連接,只有建立了連接了,才能夠有后面的交互。
一、數(shù)據(jù)庫(kù)連接池
數(shù)據(jù)庫(kù)連接池有 Druid、C3P0、DBCP
采用連接池大大節(jié)省了不斷創(chuàng)建與銷毀線程的開(kāi)銷,這就是有名的「池化」思想,不管是線程池還是 HTTP 連接池,都能看到它的身影
二、SQL 接口
MySQL 中處理請(qǐng)求的線程在獲取到請(qǐng)求以后獲取 SQL 語(yǔ)句去交給 SQL 接口去處理。
三、查詢解析器
將 SQL 接口傳遞過(guò)來(lái)的 SQL 語(yǔ)句進(jìn)行解析,翻譯成 MySQL 自己能認(rèn)識(shí)的語(yǔ)言。
四、MySQL 查詢優(yōu)化器
MySQL 會(huì)依據(jù)成本最小原則來(lái)選擇使用對(duì)應(yīng)的索引
成本 = IO 成本 + CPU 成本
IO成本 : 即從磁盤把數(shù)據(jù)加載到內(nèi)存的成本,默認(rèn)情況下,讀取數(shù)據(jù)頁(yè)的 IO 成本是 1,MySQL 是以頁(yè)的形式讀取數(shù)據(jù)的,即當(dāng)用到某個(gè)數(shù)據(jù)時(shí),并不會(huì)只讀取這個(gè)數(shù)據(jù),而會(huì)把這個(gè)數(shù)據(jù)相鄰的數(shù)據(jù)也一起讀到內(nèi)存中,這就是有名的程序局部性原理,所以 MySQL 每次會(huì)讀取一整頁(yè),一頁(yè)的成本就是 1。所以 IO 的成本主要和頁(yè)的大小有關(guān)
CPU 成本:將數(shù)據(jù)讀入內(nèi)存后,還要檢測(cè)數(shù)據(jù)是否滿足條件和排序等 CPU 操作的成本,顯然它與行數(shù)有關(guān),默認(rèn)情況下,檢測(cè)記錄的成本是 0.2。
MySQL 優(yōu)化器 會(huì)計(jì)算 「IO 成本 + CPU」 成本最小的那個(gè)索引來(lái)執(zhí)行
五、存儲(chǔ)引擎
查詢優(yōu)化器會(huì)調(diào)用存儲(chǔ)引擎的接口,去執(zhí)行 SQL,也就是說(shuō)真正執(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 中,這樣后面再有請(qǐng)求的時(shí)候就會(huì)先從緩沖池中去查詢,如果沒(méi)有再去磁盤中查找,然后在放到 Buffer Pool 中
Buffer Pool中被使用的數(shù)據(jù)回被加鎖。
八、三個(gè)日志文件
1、undo 日志文件:記錄數(shù)據(jù)被修改前的樣子
作用:利用undo 日志文件完成事務(wù)回滾
2、redo 日志文件:記錄數(shù)據(jù)被修改后的樣子
redo 記錄的是數(shù)據(jù)修改之后的值,不管事務(wù)是否提交都會(huì)記錄下來(lái)
MySQL 為了提高效率,所以將這些操作都先放在內(nèi)存中去完成,更新后的數(shù)據(jù)會(huì)記錄在 redo log buffer 中,然后會(huì)在某個(gè)時(shí)機(jī)將其持久化到磁盤中。
3、bin log 日志文件: 記錄整個(gè)操作過(guò)程
性質(zhì) | redo Log | bin Log |
---|---|---|
文件大小 | redo log 的大小是固定的(配置中也可以設(shè)置,一般默認(rèn)的就足夠了) | bin log 可通過(guò)配置參數(shù)max_bin log_size 設(shè)置每個(gè)bin log 文件的大?。ǖ且话悴唤ㄗh修改)。 |
實(shí)現(xiàn)方式 | redo log 是InnoDB 引擎層實(shí)現(xiàn)的(也就是說(shuō)是 Innodb 存儲(chǔ)引起過(guò)獨(dú)有的) | bin log 是 MySQL 層實(shí)現(xiàn)的,所有引擎都可以使用 bin log 日志 |
記錄方式 | redo log 采用循環(huán)寫的方式記錄,當(dāng)寫到結(jié)尾時(shí),會(huì)回到開(kāi)頭循環(huán)寫日志。 | bin log 通過(guò)追加的方式記錄,當(dāng)文件大小大于給定值后,后續(xù)的日志會(huì)記錄到新的文件上 |
使用場(chǎng)景 | redo log 適用于崩潰恢復(fù)(crash-safe)(這一點(diǎn)其實(shí)非常類似與 Redis 的持久化特征) | bin log 適用于主從復(fù)制和數(shù)據(jù)恢復(fù) |
bin log 記錄的是整個(gè)操作記錄(這個(gè)對(duì)于主從復(fù)制具有非常重要的意義)
以上是“執(zhí)行一句SQL的情況有哪些”這篇文章的所有內(nèi)容,感謝各位的閱讀!希望分享的內(nèi)容對(duì)大家有幫助,更多相關(guān)知識(shí),歡迎關(guān)注億速云行業(yè)資訊頻道!
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。