爲何阿里代碼規範要求SQL語句不要過多的join？

做者： 柯三

juejin.im/post/5e0443ae6fb9a0162277a2c3

送分題

面試官：有操做過Linux嗎?

我：有的呀

面試官：我想查看內存的使用狀況該用什麼命令

我：free 或者 top

面試官：那你說一下用free命令均可以看到啥信息

我：那，以下圖所示 能夠看到內存以及緩存的使用狀況

• total 總內存

• used 已用內存

• free 空閒內存

• buff/cache 已使用的緩存

• avaiable 可用內存

面試官：那你知道怎麼清理已使用的緩存嗎(buff/cache)

我：em… 不知道

面試官：sync; echo 3 > /proc/sys/vm/drop_caches就能夠清理buff/cache了，你說說我在線上執行這條命令作好很差?

我：(送分題,心裏大喜)好處大大的有，清理出緩存咱們就有更多可用的內存空間, 就跟pc上面xx衛士的火箭同樣，點一下，就釋放出好多的內存

面試官：em…., 回去等通知吧

再談SQL Join

面試官：換個話題，談談你對join的理解

我：好的（再答錯就完全完了，把握住機會)

回顧

SQL中的join能夠根據某些條件把指定的表給結合起來並將數據返回給客戶端

join的方式有

inner join 內鏈接

left join 左鏈接

right join 右鏈接

full join 全鏈接

圖片來源：https://www.cnblogs.com/reaptomorrow-flydream/p/8145610.html

面試官：在項目開發中若是須要使用join語句，如何優化提高性能?

我：分爲兩種狀況，數據規模小的，數據規模大的。

面試官: 而後?

我：對於

1.數據規模較小 所有幹進內存就完事了嗷

2.數據規模較大

• 能夠經過增長索引來優化join語句的執行速度

• 能夠經過冗餘信息來減小join的次數

• 儘可能減小錶鏈接的次數，一個SQL語句錶鏈接的次數不要超過5次

面試官：能夠總結爲join語句是相對比較耗費性能，對嗎？

我：是的

面試官: 爲何?

緩衝區

我: 在執行join語句的時候必然要有一個比較的過程

面試官: 是的

我：逐條比較兩個表的語句是比較慢的，所以咱們能夠把兩個表中數據依次讀進一個內存塊中, 以MySQL的InnoDB引擎爲例，使用如下語句咱們必然能夠查到相關的內存區域show variables like '%buffer%'

如圖所示join_buffer_size的大小將會影響咱們join語句的執行性能

面試官: 除此以外呢?

一個大前提

我：任何項目終究要上線，不可避免的要產生數據，數據的規模又不可能過小

面試官: 是這樣的

我：大部分數據庫中的數據最終要保存到硬盤上,而且以文件的形式進行存儲。

以MySQL的InnoDB引擎爲例

• InnoDB以頁(page)爲基本的IO單位，每一個頁的大小爲16KB

• InnoDB會爲每一個表建立用於存儲數據的.ibd文件

驗證

我：這意味着咱們有多少表要鏈接就須要讀多少個文件，雖然能夠利用索引，但仍是免不了頻繁的移動硬盤的磁頭

面試官：也就是說頻繁的移動磁頭會影響性能對吧

我：是的，如今的開源框架不都喜歡說本身經過順序讀寫大大的提高了性能嗎，好比hbase、kafka

面試官：說的沒錯，那你認爲Linux有對此作出優化嗎?提示，你能夠再執行一次free命令看一下

我：奇怪緩存怎麼佔用了1.2G多

圖片來源：https://www.linuxatemyram.com/

面試官：你有沒有想過

• buff/cache 裏面存的是什麼？

• 爲何buff/cache 佔了那麼多內存，可用內存即availlable還有1.1G？

• 爲何你能夠經過兩條命令來清理buff/cache佔用的內存，而想要釋放used只能經過結束進程來實現?

品，你細品

思考了幾分鐘後

我：這麼隨便就釋放了buff/cache所佔用的內存，說明它就不重要, 清除它不會對系統的運行形成影響

面試官: 不徹底對

我：難道是？想起來《CSAPP》（深刻理解計算機系統）裏面說過一句話

存儲器層次結構的本質是，每一層存儲設備都是較低一層設備的緩存

通俗來講，就是說Linux會把內存看成是硬盤的高速緩存

相關資料：http://tldp.org/LDP/sag/html/buffer-cache.html

面試官：如今知道那道送分題應該怎麼回答了吧

我：我….

Join算法

面試官：再給你個機會，若是讓你來實現Join算法你會怎麼作?

我：無索引的話,嵌套循環就完事了嗷。有索引的話，則能夠利用索引來提高性能.

面試官：說回join_buffer 你認爲join_buffer裏面存儲的是什麼?

我：在掃描過程當中，數據庫會選擇一個表把他要返回以及須要進行和其餘表進行比較的數據放進join_buffer

面試官：有索引的狀況下是怎麼處理的？

我：這個就比較簡單了，直接讀取兩個表的索引樹進行比較就完事了嗷，我這邊介紹一下無索引的處理方式

Nested Loop Join

嵌套循環，每次只讀取表中的一行數據，也就是說若是outerTable有10萬行數據, innerTable有100行數據，須要讀取10000000次(假設這兩個表的文件沒有被操做系統給緩存到內存, 咱們稱之爲冷數據表)

固然如今沒啥數據庫引擎使用這種算法（太慢了)

Block nested loop

Block 塊，也就是說每次都會取一塊數據到內存以減小I/O的開銷

當沒有索引可使用的時候，MySQL InnoDB 就會使用這種算法

考慮如下兩個表 t_a 和t_b

當沒法使用索引執行join操做的時候，InnoDB會自動使用Block nested loop 算法

總結

上學時，數據庫老師最喜歡考數據庫範式，直到上班才學會一切以性能爲準，能冗餘就冗餘，實在冗餘不了的就join若是join真的影響到性能。試着調大你的join_buffer_size, 或者換固態硬盤。

參考資料

《深刻理解計算機系統》- 第6章 存儲器層次結構
《Experiments and fun with the Linux disk cache》做者經過幾個例子來講明硬盤緩存對程序執行性能的影響
《Linux ate my ram》 Free參數的解釋
How to clear the buffer/pagecache (disk cache) under Linux 文章開頭送分題命令的解釋
MySQL 是怎樣運行的：從根兒上理解 MySQL
Block bested loop 來自MariaDB官方文檔解釋了Block-Nested-Loop算法的實現