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

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

首先，用戶想要查詢訂單數據時，會先發送一個查詢請求，如下圖所示：

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

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

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

我們來看一下，在MYSQL數據庫中是如何執行一個sql語句的，如下圖：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.尋道時間

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

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

2.旋轉延遲

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

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

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

3.數據傳輸時間

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

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

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

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

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

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

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

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

磁盤IO到底會有多慢呢？

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

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

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

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

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

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

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

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

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