天天看點

千萬資料量下的真實業務場景SQL性能優化

作者:石杉的架構筆記

前 言

通過前幾期文章的積累,現在我們的理論知識已經極為紮實了,這個時候就可以動手開始sql優化了,sql優化是非常重要,因為即使再好的MySQL設計架構,也扛不住一個頻繁查詢的垃圾sql語句。

關于sql的優化,我們也是有一定的原則和先後順序的,大體的步驟的我們用一張流程圖來看一下:

千萬資料量下的真實業務場景SQL性能優化

總體呢,大概可以分為以下幾個步驟:

(1)首先,我們得要看下sql語句中是否有join語句,比如内連接配接查詢inner join,外連接配接查詢 left join right join等;因為join語句一般都涉及到跨表查詢了,是以首先我們得要為join語句中,負責連接配接兩張表的字段建立索引,這樣的話可以利用索引加快兩張表關聯的速度。

(2)接下來,我們會再看一下sql語句中的where語句,我們可以根據目前表中的資料量,以及where語句的過濾條件,預估下查詢結果的資料量是否會很大,如果資料量很大的話,查詢的速度肯定就會很慢,是以,為了提高sql語句的執行效率,我們得要為where語句中過濾字段單獨建立索引。

(3)當我們把join語句以及where語句中的字段優化完之後,就可以來看一下其他的一些細節部分,比如sql語句中如果使用了聚合函數,或者對查詢的結果進行了排序,那麼,一般我們都建議為聚合函數中的字段,以及排序的字段都建立索引,讓這些操作利用索引速度更快點。

sql優化中不管是對where語句、聚合函數、還是排序操作的優化,優化起來相對而言會簡單點,為對應的字段建立合适的索引就可以了,但是,join語句這塊的優化涉及到一些比較重要的原理,我們還是有必要來看下的。

簡單來說,在mysql中使用join語句關聯2張表的話,比如執行這條sql:

select * from order_info t1 left join order_item_detail t2 on t1.order_no = t2.order_no           

這個時候,join關聯查詢的過程是什麼樣子的呢?其實,這個就取決于目前join語句用到的算法了,join語句一共有3種算法,最基礎的是Simple nested loop算法,接下來,我們一起來看下。

Simple nested loop算法

Simple nested loop算法,說白了就是一個雙重for循環周遊的算法,Simple nested loop算法比對的過程是這樣的:

千萬資料量下的真實業務場景SQL性能優化

從左邊的驅動表order_info中,每取出一條記錄都要周遊一遍被驅動表order_item_detail,說白了就是一個雙重for循環。

如果驅動表和被驅動表中都有100條資料的話,那麼此時就需要比對 100 * 100 = 10000次,可見效率是非常低的,是以,MySQL并沒有選擇使用 Simple nested loop 算法,而是使用了優化後的Block nested loop 算法。

Block nested loop 算法

Block nested loop 算法對 Simple nested loop 算法進行了優化,它引入了 join buffer,join buffer 主要用于優化不帶索引條件的 join 查詢,它會緩存連接配接過程中用到的字段,這樣可以有效減少比對次數,就像這樣:

千萬資料量下的真實業務場景SQL性能優化

可以看到,Block nested loop的優化思路,是減少被驅動表的比對次數,它主要是通過一次性緩存驅動表的多條資料,以此來減少被驅動表的比對次數,進而可以達到提升性能的目的。

需要注意的是,MySQL提供了一個參數join buffer_size,它是用來控制 join buffer 大小的,而MySQL預設的join_buffer_size 是 256K,是以如果驅動表的資料太多的話,預設的join buffer可能一次性放不下全部的資料。

這個時候,join buffer就會采用分段緩存的機制來緩存驅動表的資料,但是這種分段緩存方式的性能,是比一次性緩存全部資料要差一些的。

是以,我們可以通過join_buffer_size參數,适當調大join buffer的大小,使join buffer可以一次性放下驅動表的所有資料,這樣可以提升join的性能。

Index nested loop算法

最後還有一種Index nested loop算法:

千萬資料量下的真實業務場景SQL性能優化

它的優化思路主要是減少被驅動表資料的比對次數, 就是驅動表直接與被驅動表的索引進行比對,這樣就不用和被驅動表的每條記錄比較了。

原來的比對次數為:驅動表行數 * 被驅動表行數,而現在變成了:驅動表行數 * 被驅動表索引的高度,這樣就極大的減少了被驅動表的比對次數,極大的提升了join的性能。

如果join關聯查詢能使用到索引的話,MySQL就會使用Indexnestedloop算法,如果無法使用Indexnestedloop算法,MYSQL預設會使用Blocknestedloop算法。

到底能不能使用join?

好了,我們剛才了解了Simple nested loop 、 Block nested loop、Index nested loop 這三種算法,那麼現在可以回答開頭的問題了:到底能不能使用join?

其實,如果能用上被驅動表上的索引,說白了就是可以用上 Index nested loop 算法的話,是可以使用 join 的。

而如果使用的是 Block nested loop 算法的話,由于掃描行數和比較次數會比較多,是以會占用大量的系統資源,是以這種情況能不用join就不用join。

我們平常使用explain優化sql的時候,如果 explain 結果中的 Extra 字段,如果包含 ' Using join buffer (Block Nested Loop) ' 的話,這個時候就代表使用了 Block nested loop 算法了。

如果能使用上被驅動表上的索引的話,join還是可以使用的,這個時候基本不會影響性能,那麼我們這裡為什麼要優化掉join呢?

主要由于2個原因,首先後邊我們有分庫分表的計劃,是以為了有更好的擴充性,我們會優化掉join,其次MySQL是專門用來做資料存儲的,是以,還是盡量不要把業務相關的邏輯放到MySQL層面來做。

是以基于這2個原因,我們會将單體應用版本的join給優化掉。

join關聯查詢優化實戰

被驅動表order_no列未加索引

(1)join關聯查詢sql語句

千萬資料量下的真實業務場景SQL性能優化

可以看到,sql語句中,left join語句中,訂單明細表是通過order_no字段和訂單表關聯的,此時驅動表order_info的order_no是加了索引的,而被驅動表order_item_detail的order_no字段沒有添加索引

(2)看一下查詢時間

此時order_info中的資料量為2500萬條,而訂單明細表 order_item_detail 的資料量是1億條。

千萬資料量下的真實業務場景SQL性能優化

可以看到被驅動表order_item_detail沒使用到索引時,查詢效率是非常低下的。

優化:被驅動表order_no列添加索引

(1)為被驅動表添加索引

現在我們為被驅動表order_item_detail的order_no添加索引,添加索引sql如下:

create index inx_item_order_no
    on order_item_detail (order_no);           

(2)再次檢視join關聯查詢的時間

千萬資料量下的真實業務場景SQL性能優化

此時我們發現被驅動表order_item_detail的關聯字段order_no用上索引後,查詢效率提升的非常明顯。

進一步優化:去掉join

此時我們為了更好的擴充性,需要将join關聯查詢給優化掉

(1)看下join優化後的代碼:

拆分join,改成單表查詢,記憶體中再組裝資料

千萬資料量下的真實業務場景SQL性能優化

(2)看一下優化後的時間

千萬資料量下的真實業務場景SQL性能優化

可以看到,将join關聯查詢優化掉之後,我們除了可以擷取到更大的擴充性外,可以發現對查詢性能的提升也是非常大的。

被動向主動的轉變,監控系統誕生

在sql優化這個例子中,這個問題是由DBA同學發現的,然後DBA同學将問題回報給了我們,實際在工作中呢,也可能是産品同學發現訂單資訊查詢頁面有點慢,然後将問題回報給我們。

不管是誰發現的,對于我們訂單系統的開發人員來說都是非常被動的,因為我們不能及時主動的發現問題,比如某一個接口變慢了,我們不能及時知道,隻能等别人回報給我們,這樣被動的發現問題,會在一定程度上擴大問題的影響。

為了解決這個問題,我們建立了一套完善的監控系統,這個監控系統呢,可以添加很多監控面闆,比如我們可以添加訂單的監控面闆,訂單監控面闆中的核心名額包含:訂單核心接口的請求次數、失敗次數、TP50、TP99等等。

然後,為了及時發現問題,這個監控系統還內建了報警的功能,說白了就是針對某一個監控名額,我們會設定一個報警規則,比如每天的某一個時間段,在多少分鐘内,失敗請求超過多少,那麼就會報警給對應的開發人員,報警方式呢,會分為2種,分别是報警電話和消息推送(推送給公司内部的辦公聊天軟體)

報警的時候為了避免開發人員的單點故障,報警接收人一般會添加多個,如果第一個人不接報警電話的話,那麼就順延給第二個人打電話,這樣就可以最大程度的及時發現問題了,就可以真正的由被動轉為主動了。

------------- END -------------

千萬資料量下的真實業務場景SQL性能優化

另外推薦儒猿課堂的1元系列課程給您,歡迎加入一起學習~

網際網路Java工程師面試突擊課(1元專享):

https://tod.h5.xeknow.com/s/3o8O0w

SpringCloudAlibaba零基礎入門到項目實戰(1元專享):

https://tod.h5.xeknow.com/s/1NRrqb

億級流量下的電商詳情頁系統實戰項目(1元專享):

https://tod.h5.xeknow.com/s/xItYJ

Kafka消息中間件核心源碼精講(1元專享):

https://tod.h5.xeknow.com/s/1T0B9m

12個實戰案例帶你玩轉Java并發程式設計(1元專享):

https://tod.h5.xeknow.com/s/2nTSHI

Elasticsearch零基礎入門到精通(1元專享):

https://tod.h5.xeknow.com/s/40xOVv

基于Java手寫分布式中間件系統實戰(1元專享):

https://tod.h5.xeknow.com/s/1MUj1A

基于ShardingSphere的分庫分表實戰課(1元專享):

https://tod.h5.xeknow.com/s/3o6jC

繼續閱讀