這篇文章主要講解了“SQL語句執(zhí)行過程介紹”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“SQL語句執(zhí)行過程介紹”吧！
為漢中等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及漢中網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站建設(shè)、做網(wǎng)站、漢中網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
?昔日庖丁解牛，未見全牛，所賴者是其對牛內(nèi)部骨架結(jié)構(gòu)的了解，對于MySQL亦是如此，只有更加全面地了解SQL語句執(zhí)行的每個過程，才能更好的進行SQL的設(shè)計和優(yōu)化。
當希望MySQL能夠以更高的性能運行查詢時，最好的辦法就是弄清楚MySQL是如何優(yōu)化和執(zhí)行查詢的。一旦理解了這一點，很多查詢優(yōu)化工作實際上就是遵循一些原則能夠按照預(yù)想的合理的方式運行。
如下圖所示，當向MySQL發(fā)送一個請求的時候，MySQL到底做了什么：
客戶端發(fā)送一條查詢給服務(wù)器。
服務(wù)器先檢查查詢緩存，如果命中了緩存，則立刻返回存儲在緩存中的結(jié)果。否則進入下一階段。
服務(wù)器端進行SQL解析、預(yù)處理，再由優(yōu)化器生成對應(yīng)的執(zhí)行計劃。
MySQL根據(jù)優(yōu)化器生成的執(zhí)行計劃，再調(diào)用存儲引擎的API來執(zhí)行查詢。
將結(jié)果返回給客戶端。
?MySQL查詢緩存保存查詢返回的完整結(jié)構(gòu)。當查詢命中該緩存時，MySQL會立刻返回結(jié)果，跳過了解析、優(yōu)化和執(zhí)行階段。
查詢緩存系統(tǒng)會跟蹤查詢中涉及的每個表，如果這些表發(fā)生了變化，那么和這個表相關(guān)的所有緩存數(shù)據(jù)都將失效。
MySQL將緩存存放在一個引用表中，通過一個哈希值引用，這個哈希值包括了以下因素，即查詢本身、當前要查詢的數(shù)據(jù)庫、客戶端協(xié)議的版本等一些其他可能影響返回結(jié)果的信息。
當判斷緩存是否命中時，MySQL不會進行解析查詢語句，而是直接使用SQL語句和客戶端發(fā)送過來的其他原始信息。所以，任何字符上的不同，例如空格、注解等都會導(dǎo)致緩存的不命中。
當查詢語句中有一些不確定的數(shù)據(jù)時，則不會被緩存。例如包含函數(shù)NOW()或者CURRENT_DATE()的查詢不會緩存。包含任何用戶自定義函數(shù)，存儲函數(shù)，用戶變量，臨時表，mysql數(shù)據(jù)庫中的系統(tǒng)表或者包含任何列級別權(quán)限的表，都不會被緩存。
有一點需要注意，MySQL并不是會因為查詢中包含一個不確定的函數(shù)而不檢查查詢緩存，因為檢查查詢緩存之前，MySQL不會解析查詢語句，所以也無法知道語句中是否有不確定的函數(shù)。
事實則是，如果查詢語句中包含任何的不確定的函數(shù)，那么其查詢結(jié)果不會被緩存，因為查詢緩存中也無法找到對應(yīng)的緩存結(jié)果。
有關(guān)查詢緩存的配置如下所示。
query_cache_type:是否打開查詢緩存。可以設(shè)置為OFF、ON和DEMAND。DEMAND表示只有在查詢語句中明確寫明SQL_CACHE的語句才會放入查詢緩存。
query_cache_size:查詢緩存使用的總內(nèi)存空間。
query_cache_min_res_unit:在查詢緩存中分配內(nèi)存塊時的最小單元。較小的該值可以減少碎片導(dǎo)致的內(nèi)存空間浪費，但是會導(dǎo)致更頻繁的內(nèi)存塊操作。
query_cache_limit:MySQL能夠查詢的最大查詢結(jié)果。如果查詢結(jié)果大于這個值，則不會被緩存。因為查詢緩存在數(shù)據(jù)生成的時候就開始嘗試緩存數(shù)據(jù)，所以當結(jié)果全部返回后，MySQL才知道查詢結(jié)果是否超出限制。超出之后，才會將結(jié)果從查詢緩存中刪除。
?對查詢緩存的優(yōu)化是數(shù)據(jù)庫性能優(yōu)化的重要一環(huán)。判斷流程大致如下圖所示。
?緩存命中率可以通過如下公式計算：Qcache_hits/(Qcache_hits + Com_select)來計算。
?解析器通過關(guān)鍵字將SQL語句進行解析，并生成對應(yīng)的解析樹。MySQL解析器將使用MySQL語法規(guī)則驗證和解析查詢。
預(yù)處理器則根據(jù)一些MySQL規(guī)則進行進一步檢查解析書是否合法，例如檢查數(shù)據(jù)表和數(shù)據(jù)列是否存在，還會解析名字和別名，看看它們是否有歧義。
?查詢優(yōu)化器會將解析樹轉(zhuǎn)化成執(zhí)行計劃。一條查詢可以有多種執(zhí)行方法，最后都是返回相同結(jié)果。優(yōu)化器的作用就是找到這其中最好的執(zhí)行計劃。
生成執(zhí)行計劃的過程會消耗較多的時間，特別是存在許多可選的執(zhí)行計劃時。如果在一條SQL語句執(zhí)行的過程中將該語句對應(yīng)的最終執(zhí)行計劃進行緩存，當相似的語句再次被輸入服務(wù)器時，就可以直接使用已緩存的執(zhí)行計劃，從而跳過SQL語句生成執(zhí)行計劃的整個過程，進而可以提高語句的執(zhí)行速度。
?MySQL使用基于成本的查詢優(yōu)化器(Cost-Based Optimizer，CBO)。它會嘗試預(yù)測一個查詢使用某種執(zhí)行計劃時的成本，并選擇其中成本最少的一個。
優(yōu)化器會根據(jù)優(yōu)化規(guī)則對關(guān)系表達式進行轉(zhuǎn)換，這里的轉(zhuǎn)換是說一個關(guān)系表達式經(jīng)過優(yōu)化規(guī)則后會生成另外一個關(guān)系表達式，同時原有表達式也會保留，經(jīng)過一系列轉(zhuǎn)換后會生成多個執(zhí)行計劃，然后CBO會根據(jù)統(tǒng)計信息和代價模型(Cost Model)計算每個執(zhí)行計劃的Cost，從中挑選Cost最小的執(zhí)行計劃。由上可知，CBO中有兩個依賴：統(tǒng)計信息和代價模型。統(tǒng)計信息的準確與否、代價模型的合理與否都會影響CBO選擇最優(yōu)計劃。
有關(guān)優(yōu)化器的原理十分復(fù)雜，這里就不進行詳細講解了，大家可以自行學(xué)習(xí)。
?在解析和優(yōu)化階段，MySQL將生成查詢對應(yīng)的執(zhí)行計劃，MySQL的查詢執(zhí)行引擎根據(jù)這個執(zhí)行計劃來完成整個查詢。這里執(zhí)行計劃是一個數(shù)據(jù)結(jié)構(gòu)，而不是和其他的關(guān)系型數(shù)據(jù)庫那樣生成對應(yīng)的字節(jié)碼。
?如果查詢可以被緩存，那么MySQL在這個階段頁會將結(jié)果存放到查詢緩存中。
MySQL將結(jié)果集返回給客戶端是一個增量、逐步返回的過程。在查詢生成第一條結(jié)果時，MySQL就可以開始向客戶端逐步返回結(jié)果集了。
感謝各位的閱讀，以上就是“SQL語句執(zhí)行過程介紹”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對SQL語句執(zhí)行過程介紹這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識點的文章，歡迎關(guān)注！
重慶分公司
重慶分公司
