作者 | Java發財

責編 | 王曉曼

出品 | CSDN博客

送分題

面試官：有操作過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的方式有：

1、innerjoin 內連接

2、leftjoin 左連接

3、rightjoin 右連接

4、fulljoin 全連接

面試官：在項目開發中如果需要使用 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多？

面試官：你有沒有想過？buff/cache 里面存的是什么？為什么 buff/cache 占了那么多內存，可用內存即 availlable 還有1.1G？為什么你可以通過兩條命令來清理 buff/cache 占用的內存，而想要釋放used只能通過結束進程來實現?

品，你細品。

思考了幾分鐘后。

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

面試官: 不完全對。

我：難道是？想起來《CSAPP》（深入理解計算機系統）里面說過一句話：存儲器層次結構的本質是，每一層存儲設備都是較低一層設備的緩存。

通俗來說，就是說 Linux 會把內存當作是硬盤的高速緩存。

面試官：現在知道那道送分題應該怎么回答了吧。

我：我….

Join算法

面試官：再給你個機會，如果讓你來實現 Join 算法你會怎么做?

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

面試官：說回 Join_buffer 你認為 Join_buffer 里面存儲的是什么?

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

面試官：有索引的情況下是怎么處理的？

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

1、NestedLoop Join

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

當然現在沒啥數據庫引擎使用這種算法（太慢了)。

2、Blocknested loop

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

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

考慮以下兩個表 t_a 和t_b：

當無法使用索引執行 Join 操作的時候，InnoDB 會自動使用Block nested loop 算法。

上學時，數據庫老師最喜歡考數據庫范式，直到上班才學會一切以性能為準，能冗余就冗余，實在冗余不了的就 Join 如果 Join 真的影響到性能。試著調大你的 Join_buffer_size , 或者換固態硬盤。

版權聲明：本文為CSDN博主「Java發財」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。

原文鏈接：https://blog.csdn.net/weixin_47067712/article/details/105972620