分頁查詢，只有5千條數(shù)據(jù)，但因?yàn)樯婕暗降谋肀容^多，所以每次請求大約要8S左右的時(shí)間。

下面講一下優(yōu)化的過程：

系統(tǒng)框架：Spring Boot；

持久層：Spring Data JPA；

數(shù)據(jù)庫：MySql;

先貼一段Mysql語句中各個(gè)部分的執(zhí)行順序：

SQL的執(zhí)行順序

(1)from

(2) on

(3) join

(4) where

(5)group by(開始使用select中的別名，后面的語句中都可以使用)

(6) avg,sum....

(7)having

(8) select

(9) distinct

(10) order by

從這個(gè)順序中我們不難發(fā)現(xiàn)，所有的 查詢語句都是從from開始執(zhí)行的，在執(zhí)行過程中，每個(gè)步驟都會(huì)為下一個(gè)步驟生成一個(gè)虛擬表，這個(gè)虛擬表將作為下一個(gè)執(zhí)行步驟的輸入。

第一步：首先對from子句中的前兩個(gè)表執(zhí)行一個(gè)笛卡爾乘積，此時(shí)生成虛擬表 vt1（選擇相對小的表做基礎(chǔ)表）；

第二步：接下來便是應(yīng)用on篩選器，on 中的邏輯表達(dá)式將應(yīng)用到 vt1 中的各個(gè)行，篩選出滿足on邏輯表達(dá)式的行，生成虛擬表 vt2；

第三步：如果是outer join 那么這一步就將添加外部行，left outer jion 就把左表在第二步中過濾的行添加進(jìn)來，如果是right outer join 那么就將右表在第二步中過濾掉的行添加進(jìn)來，這樣生成虛擬表 vt3；

第四步：如果 from 子句中的表數(shù)目多于兩個(gè)表，那么就將vt3和第三個(gè)表連接從而計(jì)算笛卡爾乘積，生成虛擬表，該過程就是一個(gè)重復(fù)1-3的步驟，最終得到一個(gè)新的虛擬表 vt3；

第五步：應(yīng)用where篩選器，對上一步生產(chǎn)的虛擬表引用where篩選器，生成虛擬表vt4，在這有個(gè)比較重要的細(xì)節(jié)不得不說一下，對于包含outer join子句的查詢，就有一個(gè)讓人感到困惑的問題，到底在on篩選器還是用where篩選器指定邏輯表達(dá)式呢？on和where的最大區(qū)別在于，如果在on應(yīng)用邏輯表達(dá)式那么在第三步outer join中還可以把移除的行再次添加回來，而where的移除的最終的。舉個(gè)簡單的例子，有一個(gè)學(xué)生表（班級,姓名）和一個(gè)成績表(姓名,成績)，我現(xiàn)在需要返回一個(gè)x班級的全體同學(xué)的成績，但是這個(gè)班級有幾個(gè)學(xué)生缺考，也就是說在成績表中沒有記錄。為了得到我們預(yù)期的結(jié)果我們就需要在on子句指定學(xué)生和成績表的關(guān)系（學(xué)生.姓名=成績.姓名）那么我們是否發(fā)現(xiàn)在執(zhí)行第二步的時(shí)候，對于沒有參加考試的學(xué)生記錄就不會(huì)出現(xiàn)在vt2中，因?yàn)樗麄儽籵n的邏輯表達(dá)式過濾掉了,但是我們用left outer join就可以把左表（學(xué)生）中沒有參加考試的學(xué)生找回來，因?yàn)槲覀兿敕祷氐氖莤班級的所有學(xué)生，如果在on中應(yīng)用學(xué)生.班級='x'的話，left outer join會(huì)把x班級的所有學(xué)生記錄找回，所以只能在where篩選器中應(yīng)用學(xué)生.班級='x' 因?yàn)樗倪^濾是最終的；

第六步：group by 子句將中的唯一的值組合成為一組，得到虛擬表vt5。如果應(yīng)用了group by，那么后面的所有步驟都只能得到的vt5的列或者是聚合函數(shù)（count、sum、avg等）。原因在于最終的結(jié)果集中只為每個(gè)組包含一行。這一點(diǎn)請牢記；

第七步：應(yīng)用cube或者rollup選項(xiàng)，為vt5生成超組，生成vt6；

第八步：應(yīng)用having篩選器，生成vt7。having篩選器是第一個(gè)也是為唯一一個(gè)應(yīng)用到已分組數(shù)據(jù)的篩選器；

第九步：處理select子句。將vt7中的在select中出現(xiàn)的列篩選出來。生成vt8；

第十步：應(yīng)用distinct子句，vt8中移除相同的行，生成vt9。事實(shí)上如果應(yīng)用了group by子句那么distinct是多余的，原因同樣在于，分組的時(shí)候是將列中唯一的值分成一組，同時(shí)只為每一組返回一行記錄，那么所以的記錄都將是不相同的；

第十一步：應(yīng)用order by子句。按照order_by_condition排序vt9，此時(shí)返回的一個(gè)游標(biāo)，而不是虛擬表。sql是基于集合的理論的，集合不會(huì)預(yù)先對他的行排序，它只是成員的邏輯集合，成員的順序是無關(guān)緊要的。對表進(jìn)行排序的查詢可以返回一個(gè)對象，這個(gè)對象包含特定的物理順序的邏輯組織。這個(gè)對象就叫游標(biāo)。正因?yàn)榉祷刂凳怯螛?biāo)，那么使用order by 子句查詢不能應(yīng)用于表表達(dá)式。排序是很需要成本的，除非你必須要排序，否則最好不要指定order by，最后，在這一步中是第一個(gè)也是唯一一個(gè)可以使用select列表中別名的步驟。

第十二步：應(yīng)用top選項(xiàng)。此時(shí)才返回結(jié)果給請求者即用戶。

MYSQL執(zhí)行順序

SELECT語句中子句的執(zhí)行順序與SELECT語句中子句的輸入順序是不一樣的，所以并不是從SELECT子句開始執(zhí)行的，而是按照下面的順序執(zhí)行：

開始->FROM子句->WHERE子句->GROUP BY子句->HAVING子句->ORDER BY子句->SELECT子句->LIMIT子句->最終結(jié)果

這里說一下笛卡爾乘積：也叫直積

是兩個(gè)集合的直接乘積，如果不加條件限制的話會(huì)有大量冗余數(shù)據(jù)。

下面看一下實(shí)際情況中的代碼：

因?yàn)镾QL中存在count（），導(dǎo)致分頁不準(zhǔn)，所以自己重新做了分頁，

這個(gè)接口在前端調(diào)用時(shí)一共用了大約8S的時(shí)間

這不應(yīng)該是幾千條數(shù)據(jù)的查詢結(jié)果；

優(yōu)化過程

（1）在確保數(shù)據(jù)的情況下盡量小表連接大表

（2）如果有分頁，盡量把連接表的操作拿出來

（3）如果不能鏈接表單而操作單獨(dú)取出，多表聯(lián)查的時(shí)候，后面的on語句中盡量能減少直積的條數(shù)，防止下一次笛卡爾乘積過大的虛擬表

（4）如果同時(shí)執(zhí)行多條SQL，注意每條sql的連表也許不一樣，有的語句可以減少連表的數(shù)量

第一次優(yōu)化結(jié)果：

這個(gè)接口的速度變成了：

有興趣的朋友可以把max（）函數(shù)也拿出來，感覺應(yīng)該會(huì)更快。