?一次查詢的全過程是什么樣的呢？

這個時候，我們通過各種百度和Google，然后加上自己的理解，終于搞明白了MySQL一次查詢的全過程了。

首先，用戶想要查詢訂單數(shù)據(jù)時，會先發(fā)送一個查詢請求，如下圖所示：

可以看到，當用戶發(fā)送查詢請求時，因為外賣訂單項目是部署在Tomcat中的，Tomcat中的線程首先就會接收到用戶的請求，然后把請求交給外賣訂單項目。

而外賣訂單項目，會根據(jù)代碼去數(shù)據(jù)庫中查詢訂單的數(shù)據(jù)，不管是使用原生的JDBC、還是Mybatis、Hibernate等框架，其實底層都是先獲取一個JDBC連接。

通過JDBC連接，我們才可以和數(shù)據(jù)庫建立連接，然后通過JDBC的連接，到MYSQL數(shù)據(jù)庫中執(zhí)行sql語句。

我們來看一下，在MYSQL數(shù)據(jù)庫中是如何執(zhí)行一個sql語句的，如下圖：

JDBC連接是負責和MYSQL通信的，會把sql語句發(fā)給MYSQL執(zhí)行，可以看到MYSQL中，也會有線程獲取到JDBC連接中的sql語句，然后去執(zhí)行。

• 線程會把sql語句交給MYSQL中的sql接口，sql接口會轉發(fā)給sql解析器去解析，比如，sql解析器會把一條sql語句中的表名稱、WHERE關鍵字后面的查詢條件、以及具體查詢哪些字段等信息都解析出來，然后把解析好的信息交給查詢優(yōu)化器處理。
• 查詢優(yōu)化器會根據(jù)sql解析器解析好的sql語句信息，選擇一個效率最高的處理方案，來作為執(zhí)行sql語句的執(zhí)行計劃，然后轉交給執(zhí)行器去執(zhí)行。
• 而執(zhí)行器會調用MYSQL的存儲引擎，這里我們用InnoDB存儲引擎舉例，InnoDB存儲引擎中的接口就會來執(zhí)行sql語句，如下圖：

可以看到，MYSQL InnoDB存儲引擎中，有一塊內存區(qū)域叫做Buffer Pool，也叫做緩沖池，一般情況，MYSQL的數(shù)據(jù)都存放在磁盤中，如果你去查詢數(shù)據(jù)，數(shù)據(jù)就會從磁盤加載到MYSQL內存中，也就是放在緩沖池Buffer Pool中。

而Buffer Pool，如果我們要再細分一下的話，可以看到是由多個chunk組成的，每個chunk大概占128MB內存的大小，每個chunk中都有多個緩存頁，每個緩存頁的大小是16kb，緩存頁就是用來存放加載到內存的數(shù)據(jù)的。

每個緩存頁都有個對應的描述數(shù)據(jù)塊，可以把描述數(shù)據(jù)理解為緩存頁的一個指針，通過描述數(shù)據(jù)就可以找到對應的緩存頁。

這個時候，當InnoDB存儲引擎執(zhí)行sql語句查詢數(shù)據(jù)時，首先，得要從磁盤中加載數(shù)據(jù)，如下圖：

這里的表空間呢，指的是獨立表空間，在MySQL中，表空間分為2種，分別是共享表空間和獨立表空間， 不過在MySQL 5.6.6及后續(xù)版本默認使用的是獨立表空間，說白了就是一個獨立表空間在磁盤中會單獨對應一個表空間文件，而一個表空間文件存放著MYSQL數(shù)據(jù)庫中一張表的數(shù)據(jù)。

在表空間中有很多數(shù)據(jù)區(qū)組，每個數(shù)據(jù)區(qū)組中包含256個數(shù)據(jù)區(qū)，而每個數(shù)據(jù)區(qū)中又包含64個數(shù)據(jù)頁，因為每個數(shù)據(jù)頁的大小默認是16KB，所以也就是說一個數(shù)據(jù)區(qū)的大小是1MB。

從磁盤加載數(shù)據(jù)到MYSQL內存中，其實就是通過磁盤IO的方式，把數(shù)據(jù)頁中的數(shù)據(jù)加載到緩沖池Buffer Pool中的緩存頁中，然后通過InnoDB存儲引擎和sql接口，一步步返回給用戶。

那么，在查詢的整個流程中，哪個環(huán)節(jié)最容易拖后腿呢？ 答案就是磁盤IO，也就是將磁盤中的數(shù)據(jù)頁數(shù)據(jù)讀取到Buffer Pool的緩存頁這個過程。

那么，磁盤IO為什么會拖后腿呢？磁盤IO的過程大概是什么樣子的呢？接下來，就很有必要來看下這一塊內容了。

查詢慢深層次原因揭秘：磁盤IO的過程

先來看下磁盤的物理結構，如下圖：

磁盤內部的組成部分，主要為主軸、磁盤盤片、讀寫磁頭、傳動軸和傳動手臂，其中數(shù)據(jù)就是存放在磁盤盤片上的，磁盤盤片被劃分為了無數(shù)個小扇區(qū)，每個扇區(qū)中都有很多半徑不同的環(huán)形磁道，不同的磁道中存放著不同的數(shù)據(jù)。

在實際讀寫數(shù)據(jù)時，主軸會讓磁盤盤片轉動，然后再通過傳動手臂的伸展，讓讀寫磁頭在磁盤扇區(qū)的磁道上讀取和寫入數(shù)據(jù)，一次磁盤IO花費的時間，主要由尋道時間、旋轉延遲和數(shù)據(jù)傳輸時間三部分構成，接下來，我們分別來看下這三部分的耗時情況。

1.尋道時間

剛才我們知道了，磁盤盤片表面上被分為了無數(shù)小扇區(qū)，每個扇區(qū)中都有很多半徑不同的磁道，不同的磁道上放著不同的數(shù)據(jù)。

而尋道時間，指的是將讀寫磁頭移動到正確半徑的磁道上所需要的時間，尋道時間越短，磁盤IO操作越快，目前磁盤的平均尋道時間，一般在3~15ms，主流磁盤一般在5ms以下。

2.旋轉延遲

尋道結束后，還需要讀寫磁頭旋轉到這個磁道的正確位置上才能讀寫數(shù)據(jù)，而旋轉延遲，指的是從尋道時間結束開始，到讀寫磁頭旋轉到磁道正確位置的這段時間間隔。

但是，我們一般將磁盤旋轉周期值的一半，作為旋轉延遲的近似值；常見的磁盤轉速有5400轉和7200轉，表示每分鐘能轉5400和7200圈。

比如，我們以7200轉舉例，也就是說1秒鐘能轉120圈，磁盤的旋轉周期就是 1/120 秒，所以，旋轉延遲的近似值為 1/120/2 = 4.17ms。

3.數(shù)據(jù)傳輸時間

傳輸時間，指的是將數(shù)據(jù)從磁盤盤片讀出或寫入的時間，一般在零點幾毫秒，相對于前兩個時間幾乎可以忽略不計，這樣來看訪問一次磁盤即一次磁盤IO的時間，約等于 5ms + 4.17ms = 9ms。

磁盤的順序讀寫和隨機讀寫

#另外，磁盤的數(shù)據(jù)讀寫，分為隨機讀寫和順序讀寫這兩種，這兩種讀寫數(shù)據(jù)的方式，與讀寫磁頭讀寫數(shù)據(jù)的方式有關。

順序讀寫， 顧名思義就是讀寫磁頭從磁盤中的一個位置，按照順序依次讀寫磁盤盤片中的數(shù)據(jù)，速度還是挺快的，比如像MYSQL的redo log日志、binglog日志這些日志信息，比如，順序寫數(shù)據(jù)時，會相應在一個大日志文件末尾，按照順序添加日志信息。

隨機讀寫時，讀寫磁頭則會在磁盤盤片中，隨機切換到不同半徑的磁道上讀寫數(shù)據(jù)，頻繁切換磁道的這個過程，是非常耗時的。

所以，隨機讀寫的速度相比于順序讀寫來說，是會慢很多的，而MYSQL從磁盤中讀寫數(shù)據(jù)，正好是比較耗時的隨機讀寫。

正是因為從MYSQL中查詢數(shù)據(jù)，往往要發(fā)生多次耗時的隨機IO，所以，我們對于一些對查詢效率要求較高的數(shù)據(jù)，一般都會選擇固態(tài)硬盤來存放。

固態(tài)硬盤的工作原理，簡單來說就是通過電子的移動來實現(xiàn)數(shù)據(jù)的讀寫，相比于磁盤這種物理機械的運作方式，速度是快很多的，但是固態(tài)硬盤是比較貴的，基于成本考慮，一般公司大部分機器還是會選擇普通機械磁盤的。

磁盤IO到底會有多慢呢？

我們回到剛才，已經知道磁盤IO的工作原理，我們也簡單計算了一下，一次磁盤IO大概是9ms的樣子，看上去還可以，但是9ms已經非常慢了，那到底有多慢呢，我們可以和內存的速度對比一下。

一般一次內存隨機讀取的速度，大概在100ns以內，而 1ms = 1000000ns，可以看到，一次磁盤IO耗時是毫秒級的，而內存是納秒級的。

9ms = 9 * 1000000 ns / 100 ns = 90000，說白了磁盤的速度比內存慢 9萬倍左右，那為什么從內存讀寫數(shù)據(jù)會那么快呢，簡單來說，內存其實是被CPU控制的，而CPU的時鐘頻率的速度相比于磁盤機械運轉速度，速度可以說是非常快了。

當用戶發(fā)起一次查詢請求，一次磁盤IO一般是搞不定的，具體發(fā)生磁盤IO的次數(shù)，還得要取決于B+樹的高度和當時使用索引的情況。

極端情況下，比如沒用到索引，一次查詢可能會發(fā)生100多次磁盤IO，這時，磁盤IO所需的總時間大概是 9ms * 100 = 900ms，也就是0.9秒，這就差不多到秒級別了。

隨著數(shù)據(jù)的快速增長，比如達到了好幾億的數(shù)據(jù)量，那需要的磁盤IO次數(shù)會大幅增加，那這個時候，一次查詢所需要的時間，就會達到好幾秒。

用戶查詢請求慢的根本原因

現(xiàn)在，我們知道用戶查詢請求慢的根本原因了嗎？

其實說白了，就是隨著數(shù)據(jù)表中的數(shù)據(jù)量，變得越來越大，導致磁盤IO發(fā)生的次數(shù)也相應變多了，如果我們能把磁盤IO的次數(shù)降到常數(shù)級別，那么查詢速度是非?？斓?，所以，后邊的優(yōu)化都是以降低磁盤IO次數(shù)為目標。?