一、SQL ：一種熟悉又陌生的編程語(yǔ)言

這里有幾個(gè)關(guān)鍵詞;“熟悉”、“陌生”、“編程語(yǔ)言”。

說(shuō)它“熟悉”，是因?yàn)樗荄BA和廣大開(kāi)發(fā)人員，操作數(shù)據(jù)庫(kù)的主要手段，幾乎每天都在使用。說(shuō)它“陌生”，是很多人只是簡(jiǎn)單的使用它，至于它是怎么工作的?如何才能讓它更高效的工作?卻從來(lái)沒(méi)有考慮過(guò)。

[[271147]]

這里把SQL歸結(jié)為一種“編程語(yǔ)言”，可能跟很多人對(duì)它的認(rèn)知不同。讓我們看看它的簡(jiǎn)單定義(以下內(nèi)容摘自百度百科)

結(jié)構(gòu)化查詢語(yǔ)言(Structured Query Language)，簡(jiǎn)稱(chēng)SQL，是一種特殊目的的編程語(yǔ)言，是一種數(shù)據(jù)庫(kù)查詢和程序設(shè)計(jì)語(yǔ)言，用于存取數(shù)據(jù)以及查詢、更新和管理關(guān)系數(shù)據(jù)庫(kù)系統(tǒng)。結(jié)構(gòu)化查詢語(yǔ)言是高級(jí)的非過(guò)程化編程語(yǔ)言，允許用戶在高層數(shù)據(jù)結(jié)構(gòu)上工作。它不要求用戶指定對(duì)數(shù)據(jù)的存放方法，也不需要用戶了解具體的數(shù)據(jù)存放方式，所以具有完全不同底層結(jié)構(gòu)的不同數(shù)據(jù)庫(kù)系統(tǒng), 可以使用相同的結(jié)構(gòu)化查詢語(yǔ)言作為數(shù)據(jù)輸入與管理的接口。結(jié)構(gòu)化查詢語(yǔ)言語(yǔ)句可以嵌套，這使它具有極大的靈活性和強(qiáng)大的功能。

總結(jié)一句話，SQL是一種非過(guò)程化的的編程語(yǔ)言，可通過(guò)它去訪問(wèn)關(guān)系型數(shù)據(jù)庫(kù)系統(tǒng)。

二、你真的了解“SQL”嗎?

下面我會(huì)通過(guò)一個(gè)小例子，看看大家是否真正了解SQL。

這是一個(gè)很簡(jiǎn)單的示例，是關(guān)于SQL語(yǔ)句執(zhí)行順序的。這里將一個(gè)普通的SELECT語(yǔ)句，拆分為三個(gè)子句。那么在實(shí)際的執(zhí)行過(guò)程中，是按照什么順序處理的呢?這里有A-F六個(gè)選項(xiàng)，大家可以思考選擇一下…

最終的答案是D，即按照先執(zhí)行FROM子句，然后WHERE子句，最后是SELECT部分。

針對(duì)上面的示例，讓我們真實(shí)構(gòu)造一個(gè)場(chǎng)景，通過(guò)查看執(zhí)行計(jì)劃看看是否按照我們選擇的順序執(zhí)行的。關(guān)于執(zhí)行計(jì)劃的判讀，我后面會(huì)專(zhuān)門(mén)談到。這里我先解釋一下整個(gè)執(zhí)行過(guò)程。

第一步，是按照全表掃描的方式訪問(wèn)了對(duì)象表(EMP)。對(duì)應(yīng)于語(yǔ)句中的FROM部分。

第二步，是對(duì)提取出的結(jié)果集進(jìn)行了過(guò)濾(filter部分)，即將滿足條件的記錄篩選出來(lái)。對(duì)應(yīng)于語(yǔ)句中的WHERE部分。

第三步，是對(duì)滿足條件的記錄進(jìn)行字段投射，即將需要顯示的字段提取出來(lái)。對(duì)應(yīng)于語(yǔ)句中的SELECT部分。

這是一個(gè)詳細(xì)的SQL各部分執(zhí)行順序的說(shuō)明。

通過(guò)對(duì)執(zhí)行順序的理解，可以為我們未來(lái)的優(yōu)化工作帶來(lái)很大幫助。一個(gè)很淺顯的認(rèn)識(shí)就是，優(yōu)化動(dòng)作越靠前越好。

三、SQL現(xiàn)在是否仍然重要?

這里引入了一個(gè)新的問(wèn)題，在現(xiàn)有階段SQL語(yǔ)言是否還重要?

之所以引入這一話題，是因?yàn)殡S著NOSQL、NEWSQL、BIGDATA等技術(shù)逐步成熟推廣，“SQL語(yǔ)言在現(xiàn)階段已經(jīng)變得不那么重要”成為一些人的觀點(diǎn)。那實(shí)際情況又是如何呢?、

讓我們先來(lái)看一張經(jīng)典的圖。圖中描述了傳統(tǒng)SMP架構(gòu)的關(guān)系型數(shù)據(jù)庫(kù)、MPP架構(gòu)的NEWSQL、MPP架構(gòu)的NoSQL不同方案的適用場(chǎng)景對(duì)比。

從上面的“數(shù)據(jù)價(jià)值密度、實(shí)時(shí)性”來(lái)看，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)適合于價(jià)值密度更高、實(shí)時(shí)性要求更高的場(chǎng)景(這也就不難理解類(lèi)似賬戶、金額類(lèi)信息都是保存在傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)中);MPP架構(gòu)的NewSQL次之，MPP架構(gòu)的NoSQL更適合于低價(jià)值、實(shí)時(shí)性要求不高的場(chǎng)景。

從下面的“數(shù)據(jù)規(guī)模”來(lái)看，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)適合保存的大小限制在TB級(jí)別，而后兩者可在更大尺度上(PB、EB)級(jí)保存數(shù)據(jù)。

從下面的“典型場(chǎng)景”來(lái)看，傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)適合于OLTP在線交易系統(tǒng);MPP架構(gòu)的NewSQL適合于OLAP在線分析系統(tǒng);而NoSQL的使用場(chǎng)景較多(利于KV型需求、數(shù)據(jù)挖掘等均可以考慮)。

最后從“數(shù)據(jù)特征”來(lái)看，前兩者適合于保存結(jié)構(gòu)化數(shù)據(jù)，后者更適合于半結(jié)構(gòu)化、乃至非結(jié)構(gòu)化數(shù)據(jù)的保存。

歸納一下，不同技術(shù)有其各自特點(diǎn)，不存在誰(shuí)代替誰(shuí)的問(wèn)題。傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)有其自身鮮明特點(diǎn)，在某些場(chǎng)合依然是不二選擇。而作為其主要交互語(yǔ)言，SQL必然長(zhǎng)期存在發(fā)展下去。

我們?cè)賮?lái)對(duì)比一下傳統(tǒng)數(shù)據(jù)庫(kù)與大數(shù)據(jù)技術(shù)。從數(shù)據(jù)量、增長(zhǎng)型、多樣化、價(jià)值等維度對(duì)比兩種技術(shù)，各自有其適用場(chǎng)景。

對(duì)于大數(shù)據(jù)領(lǐng)域而言，各種技術(shù)層出不窮。但對(duì)于廣大使用者來(lái)說(shuō)，往往會(huì)存在一定的使用門(mén)檻，因此現(xiàn)在的一種趨勢(shì)就是在大數(shù)據(jù)領(lǐng)域也引入“類(lèi)SQL”，以類(lèi)似SQL的方式訪問(wèn)數(shù)據(jù)。這對(duì)于廣大使用者來(lái)說(shuō)，無(wú)疑大大降低了使用門(mén)檻。

解答一些疑問(wèn)：

NoSQL、NewSQL已經(jīng)超越了傳統(tǒng)數(shù)據(jù)庫(kù)，SQL沒(méi)有了用武之地!

各種技術(shù)有著各自適合的不同場(chǎng)景，不能一概而論。SQL語(yǔ)言作為關(guān)系型數(shù)據(jù)庫(kù)的主要訪問(wèn)方式，依然有其用武之地。

以后都是云時(shí)代了，誰(shuí)還用關(guān)系型數(shù)據(jù)庫(kù)!

對(duì)于價(jià)值密度高，嚴(yán)格一致性的場(chǎng)景，仍然適合采用關(guān)系型數(shù)據(jù)庫(kù)作為解決方案。

我編程都是用OR Mapping工具，從不需要寫(xiě)SQL!

的確，引入OR Mapping工具大大提高了生產(chǎn)效率，但是它的副作用也很明顯，那就是對(duì)語(yǔ)句的運(yùn)行效率失去了控制。很多低效的語(yǔ)句，往往是通過(guò)工具直接生成的。這也是為什么有的Mapping工具還提供了原始的SQL接口，用來(lái)保證關(guān)鍵語(yǔ)句的執(zhí)行效率。

大數(shù)據(jù)時(shí)代，我們都用Hadoop、Spark了，不用寫(xiě)SQL啦!

無(wú)論是使用Hadoop、Spark都是可以通過(guò)編寫(xiě)程序完成數(shù)據(jù)分析的，但其生產(chǎn)效率往往很低。這也是為什么產(chǎn)生了Hive 、Spark SQL等“類(lèi)SQL”的解決方案來(lái)提高生產(chǎn)效率。

數(shù)據(jù)庫(kù)處理能力很強(qiáng)，不用太在意SQL性能!

的確，隨著多核CPU、大內(nèi)存、閃存等硬件技術(shù)的發(fā)展，數(shù)據(jù)庫(kù)的處理能力較以前有了很大的增強(qiáng)。但是SQL的性能依然很重要。后面我們可以看到，一個(gè)簡(jiǎn)單SQL語(yǔ)句就可以輕易地搞垮一個(gè)數(shù)據(jù)庫(kù)。

SQL優(yōu)化，找DBA就行了，我就不用學(xué)了!

SQL優(yōu)化是DBA的職責(zé)范疇，但對(duì)于開(kāi)發(fā)人員來(lái)講，更應(yīng)該對(duì)自己的代碼負(fù)責(zé)。如果能在開(kāi)發(fā)階段就注重SQL質(zhì)量，會(huì)避免很多低級(jí)問(wèn)題。

我只是個(gè)運(yùn)維DBA，SQL優(yōu)化我不行!

DBA的發(fā)展可分為“運(yùn)維DBA->開(kāi)發(fā)DBA->數(shù)據(jù)架構(gòu)師…”。如果只能完成數(shù)據(jù)庫(kù)的運(yùn)維類(lèi)工作，無(wú)疑是技能的欠缺，也是對(duì)各人未來(lái)發(fā)展不利。況且，隨著Paas云的逐步推廣，對(duì)于數(shù)據(jù)庫(kù)的運(yùn)維需求越來(lái)越少，對(duì)于優(yōu)化、設(shè)計(jì)、架構(gòu)的要求越來(lái)越多。因此，SQL優(yōu)化是每個(gè)DBA必須掌握的技能。

現(xiàn)在優(yōu)化有工具了，很簡(jiǎn)單的!

的確現(xiàn)在有些工具可以為我們減少些優(yōu)化分析工作，會(huì)自動(dòng)給出一些優(yōu)化建議。但是，作為DBA來(lái)講，不僅要知其然，還要知其所以然。況且，數(shù)據(jù)庫(kù)優(yōu)化器本身就是一個(gè)非常復(fù)雜的組件，很難做到完全無(wú)誤的優(yōu)化，這就需要人工的介入，分析。

優(yōu)化不就是加索引嘛，這有啥!

的確，加索引是一個(gè)非常常用的優(yōu)化手段，但其不是唯一的。且很多情況下，加了索引可能導(dǎo)致性能更差。后面，會(huì)有一個(gè)案例說(shuō)明。

四、SQL仍然很重要!

我們通過(guò)一個(gè)示例，說(shuō)明一下理解SQL運(yùn)行原理仍然很重要。

這是我在生產(chǎn)環(huán)境碰到的一個(gè)真實(shí)案例。Oracle數(shù)據(jù)庫(kù)環(huán)境，兩個(gè)表做關(guān)聯(lián)。執(zhí)行計(jì)劃觸目驚心，優(yōu)化器評(píng)估返回的數(shù)據(jù)量為3505T條記錄，計(jì)劃返回量127P字節(jié)，總成本9890G，返回時(shí)間999:59:59。

從執(zhí)行計(jì)劃中可見(jiàn)，兩表關(guān)聯(lián)使用了笛卡爾積的關(guān)聯(lián)方式。我們知道笛卡爾連接是指在兩表連接沒(méi)有任何連接條件的情況。一般情況下應(yīng)盡量避免笛卡爾積，除非某些特殊場(chǎng)合。否則再?gòu)?qiáng)大的數(shù)據(jù)庫(kù)，也無(wú)法處理。這是一個(gè)典型的多表關(guān)聯(lián)缺乏連接條件，導(dǎo)致笛卡爾積，引發(fā)性能問(wèn)題的案例。

從案例本身來(lái)講，并沒(méi)有什么特別之處，不過(guò)是開(kāi)發(fā)人員疏忽，導(dǎo)致了一條質(zhì)量很差的SQL。但從更深層次來(lái)講，這個(gè)案例可以給我們帶來(lái)如下啟示：

開(kāi)發(fā)人員的一個(gè)疏忽，造成了嚴(yán)重的后果，原來(lái)數(shù)據(jù)庫(kù)竟是如此的脆弱。需要對(duì)數(shù)據(jù)庫(kù)保持一種"敬畏"之心。

電腦不是人腦，它不知道你的需求是什么，只能用寫(xiě)好的邏輯進(jìn)行處理。

不要去責(zé)怪開(kāi)發(fā)人員，誰(shuí)都會(huì)犯錯(cuò)誤，關(guān)鍵是如何從制度上保證不再發(fā)生類(lèi)似的問(wèn)題。

五、SQL優(yōu)化法則

下面我們來(lái)看看常見(jiàn)的優(yōu)化法則。這里所說(shuō)的優(yōu)化法則，其實(shí)是指可以從那些角度去考慮SQL優(yōu)化的問(wèn)題。可以有很多種方式去看待它。下面列舉一二。

這里來(lái)自阿里-葉正盛的一篇博客里的一張圖，相信很多人都看過(guò)。這里提出了經(jīng)典的漏斗優(yōu)化法則，高度是指我們投入的資源，寬度是指可能實(shí)現(xiàn)的收益。從圖中可見(jiàn)，“減少數(shù)據(jù)訪問(wèn)”是投入資源最少，而收益較多的方式;“增加硬件資源”是相對(duì)投入資源最多，而收益較少的一種方式。受時(shí)間所限，這里不展開(kāi)說(shuō)明了。

這是我總結(jié)的一個(gè)優(yōu)化法則，簡(jiǎn)稱(chēng)為“DoDo”法則。

第一條，“Do Less or not do!”翻譯過(guò)來(lái)，就是盡量讓數(shù)據(jù)庫(kù)少做工作、甚至不做工作。

怎么樣來(lái)理解少做工作呢?比如創(chuàng)建索引往往可以提高訪問(wèn)效率，其原理就是將原來(lái)的表掃描轉(zhuǎn)換為索引掃描，通過(guò)一個(gè)有序的結(jié)構(gòu)，只需要少量的IO訪問(wèn)就可以得到相應(yīng)的數(shù)據(jù)，因此效率才比較高。這就可以歸納為少做工作。

怎么樣來(lái)理解不做工作呢?比如在系統(tǒng)設(shè)計(jì)中常見(jiàn)的緩存設(shè)計(jì)，很多是將原來(lái)需要訪問(wèn)數(shù)據(jù)庫(kù)的情況，改為訪問(wèn)緩存即可。這樣既提高了訪問(wèn)效率，又減少了數(shù)據(jù)庫(kù)的壓力。從數(shù)據(jù)庫(kù)角度來(lái)說(shuō)，這就是典型的不做工作。

第二條，“If must do,do it fast!”翻譯過(guò)來(lái)，如果數(shù)據(jù)庫(kù)必須做這件事件，那么請(qǐng)盡快做完它。

怎么樣來(lái)理解這句話呢?比如數(shù)據(jù)庫(kù)里常見(jiàn)的并行操作，就是通過(guò)引入多進(jìn)程來(lái)加速原來(lái)的執(zhí)行過(guò)程。加速處理過(guò)程，可以少占用相關(guān)資源，提高系統(tǒng)整體吞吐量。

六、SQL 執(zhí)行過(guò)程

SQL的執(zhí)行過(guò)程比較復(fù)雜，不同數(shù)據(jù)庫(kù)有一定差異。下面介紹以兩種主流的數(shù)據(jù)庫(kù)(Oracle、MySQL)介紹一下。

用戶提交了一條SQL語(yǔ)句

數(shù)據(jù)庫(kù)按照SQL語(yǔ)句的字面值計(jì)算出一個(gè)HASH值

根據(jù)HASH值，判斷一下在數(shù)據(jù)庫(kù)緩沖區(qū)中是否存在此SQL的執(zhí)行計(jì)劃。

如果不存在，則需要生成一個(gè)執(zhí)行計(jì)劃(硬解析過(guò)程)，然后將結(jié)果存入緩沖區(qū)。

如果存在的話，判斷是否為相同SQL(同樣HASH值的語(yǔ)句，可能字符不相同;即使完全相同，也可能代表不同的語(yǔ)句。這塊不展開(kāi)說(shuō)了)

確認(rèn)是同一條SQL語(yǔ)句，則從緩沖區(qū)中取出執(zhí)行計(jì)劃。

將執(zhí)行計(jì)劃，交給執(zhí)行器執(zhí)行。

結(jié)果返回給客戶端。

客戶提交一條語(yǔ)句

現(xiàn)在查詢緩存查看是否存在對(duì)應(yīng)的緩存數(shù)據(jù)，如有則直接返回(一般有的可能性極小，因此一般建議關(guān)閉查詢緩存)。

交給解析器處理，解析器會(huì)將提交的語(yǔ)句生成一個(gè)解析樹(shù)。

預(yù)處理器會(huì)處理解析樹(shù)，形成新的解析樹(shù)。這一階段存在一些SQL改寫(xiě)的過(guò)程。

改寫(xiě)后的解析樹(shù)提交給查詢優(yōu)化器。查詢優(yōu)化器生成執(zhí)行計(jì)劃。

執(zhí)行計(jì)劃交由執(zhí)行引擎調(diào)用存儲(chǔ)引擎接口，完成執(zhí)行過(guò)程。這里要注意，MySQL的Server層和Engine層是分離的。

最終的結(jié)果有執(zhí)行引擎返回給客戶端，如果開(kāi)啟查詢緩存的話，則會(huì)緩存。

七、SQL優(yōu)化器

在上面的執(zhí)行過(guò)程描述中，多次提高了優(yōu)化器。它也是數(shù)據(jù)庫(kù)中最核心的組件。下面我們來(lái)介紹一下優(yōu)化器。

上面是我對(duì)優(yōu)化器的一些認(rèn)識(shí)。優(yōu)化器是數(shù)據(jù)庫(kù)的精華所在，值得DBA去認(rèn)真研究。但是遺憾的是，數(shù)據(jù)庫(kù)對(duì)這方面的開(kāi)放程度并不夠。(相對(duì)來(lái)說(shuō)，Oracle還是做的不錯(cuò)的)

這里我們看到的MySQL的優(yōu)化器的工作過(guò)程，大致經(jīng)歷了如下處理：

詞法分析、語(yǔ)法分析、語(yǔ)義檢查

預(yù)處理階段(查詢改寫(xiě)等)

查詢優(yōu)化階段(可詳細(xì)劃分為邏輯優(yōu)化、物理優(yōu)化兩部分)

查詢優(yōu)化器優(yōu)化依據(jù)，來(lái)自于代價(jià)估算器估算結(jié)果(它會(huì)調(diào)用統(tǒng)計(jì)信息作為計(jì)算依據(jù))

交由執(zhí)行器執(zhí)行

此圖是DBAplus社群MySQL原創(chuàng)專(zhuān)家李海翔對(duì)比不同數(shù)據(jù)庫(kù)優(yōu)化器技術(shù)所總結(jié)的。從這里可以看出：

不同數(shù)據(jù)庫(kù)的實(shí)現(xiàn)層次不同，有些支持、有些不支持

即使支持，其實(shí)現(xiàn)原理也差異很大

這只是列出了一小部分優(yōu)化技術(shù)

以上對(duì)比，也可以解釋不同數(shù)據(jù)庫(kù)對(duì)同樣語(yǔ)句的行為不同。下面會(huì)有一個(gè)示例說(shuō)明

八、SQL 執(zhí)行計(jì)劃

看懂執(zhí)行計(jì)劃是DBA優(yōu)化的前提之一，它為我們開(kāi)啟一扇通往數(shù)據(jù)庫(kù)內(nèi)部的窗口。但是很遺憾，從沒(méi)有一本書(shū)叫做“如何看懂執(zhí)行計(jì)劃”，這里的情況非常復(fù)雜，很多是需要DBA常年積累而成。

這是Oracle執(zhí)行計(jì)劃簡(jiǎn)單的示例，說(shuō)明了執(zhí)行計(jì)劃的大致內(nèi)容。