《吊打面試官》系列-數據庫基礎知識

https://mp.weixin.qq.com/s/NDL1Q6nqdPq5oMBWSpq4ug

《吊打面試官》系列-數據庫基礎知識

收錄於話題#程序員 1568 #數據庫 642

前言

數據庫我想你們應該一點都不陌生吧，我想無論你寫啥的，數據庫就算沒用過也聽過了，是咱們項目體系裏面不可或缺的一環。

問了一圈，身邊朋友公司要麼用自研，要麼就清一色的MySQL，因此想看Oracle的朋友可能要失望了，可是不影響你瞭解數據庫的通用知識。

正文

你知道MySQL的基本架構麼？你能在紙上給我大體畫出這個示意圖麼？

好的那咱們按照順序瞭解下，鏈接器是啥？

咱們要進行查詢，第一步就是先去連接數據庫，那這個時候就是鏈接器跟咱們對接。

他負責跟客戶端創建連接、獲取權限、維持和管理鏈接。

連接的時候會通過TCP握手，而後身份驗證，而後咱們輸入用戶名密碼就行了。

驗證ok後，咱們就連上了這個MySQL服務了，可是這個時候咱們處於空閒狀態。

怎麼查看空閒鏈接列表？

show processlist，下圖就是我在本身的數據庫表執行命令的結果，其中的Command列顯示爲Sleep的這一行，就表示如今系統裏面有一個空閒鏈接。

這裏須要注意的是，咱們數據庫的客戶端過久沒響應，鏈接器就會自動斷開了，這個時間參數是wait_timeout控制住的，默認時長爲8小時。

斷開後重連的時候會報錯，若是你想再繼續操做，你就須要重連了。

這個有個我看過的書本的案例：

一個在政府裏的朋友說，他們的系統很奇怪，天天早上都得重啓一下應用程序，不然就提示鏈接數據庫失敗，他們都不知道該怎麼辦。

按照這個錯誤提示，應該就是鏈接時間過長了，斷開了鏈接。

數據庫默認的超時時間是8小時，而他們平時六點下班，下班以後系統就沒有人用了，等到次日早上九點甚至十點才上班，這中間的時間已經超過10個小時了，數據庫的鏈接確定就會斷開了。

是的，就是超出了超時時間，而後寫代碼的人也沒注意到這個細節，因此纔會出現這個問題。

把超時時間改得長一點，問題就解決了。

這種參數其實咱們平時不必定能接觸到，可是真的遇到問題的時候，知道每一個參數的大概用法，不至於讓你變成無頭蒼蠅。

那除了從新連接，還有別的方式麼？由於創建連接仍是比較麻煩的。

使用長鏈接。

可是這裏有個缺點，使用長鏈接以後，內存會飆得很快，咱們知道MySQL在執行過程當中臨時使用的內存是管理在鏈接對象裏面的。

只有在連接斷開的時候才能獲得釋放，那若是一直使用長鏈接，那就會致使OOM（Out Of Memory），會致使MySQL重啓，在JVM裏面就會致使頻繁的Full GC。

那你會怎麼解決？

我通常會按期斷開長鏈接，使用一段時間後，或者程序裏面判斷執行過一個佔用內存比較大的查詢後就斷開鏈接，須要的時候重連就行了。

還有別的方法麼？你這種感受不優雅呀小老弟。

執行比較大的一個查詢後，執行mysql_reset_connection能夠從新初始化鏈接資源。這個過程相比上面一種會好點，不須要重連，可是會初始化鏈接的狀態。

你瞭解MySQL的查詢緩存麼？

MySQL拿到一個查詢請求後，會先到查詢緩存看看，以前是否是執行過這條語句。

你們是否是好奇同一條語句在MySQL執行兩次，第一次和後面的時間是不同的，後者明顯快一些，這就是由於緩存的存在。

他跟Redis同樣，只要是你以前執行過的語句，都會在內存裏面用key-value形式存儲着。

查詢的時候就會拿着語句先去緩存中查詢，若是可以命中就返回緩存的value，若是不命中就執行後面的階段。

可是我仍是不喜歡用緩存，由於緩存弊大於利。

哦？此話怎講？

緩存的失效很容易，只要對錶有任何的更新，這個表的全部查詢緩存就會所有被清空，就會出現緩存還沒使用，就直接被清空了，或者積累了不少緩存準備用來着，可是一個更新打回原形。

這就致使查詢的命中率低的可怕，只有那種只查詢不更新的表適用緩存，可是這樣的表每每不多存在，通常都是什麼配置表之類的。

那咱們查詢的時候不想用緩存通常都是怎麼操做的，或者是用緩存又怎麼操做？

能夠顯示調用，把query_cache_type設置成爲DEMAND，這樣SQL默認不適用緩存，想用緩存就用SQL_CACHE。

有個小技巧就是，咱們以前開發的時候，都會去庫裏看看sql執行時間，可是多是有緩存的，通常咱們就在sql前面使用SQL_NO_CACHE就能夠知道真正的查詢時間了。

 select SQL_NO_CACHE * from B

緩存在MySQL8.0以後就取消了，因此你們如今應該不須要太關注這個問題，主要是我以前用的版本都不高，因此緩存一直有，在《高性能MySQL》書中也看到了一些關於緩存的介紹，就想起來給你們也提一下了。

緩存查詢完了應該作啥呢？

在緩存沒有命中的狀況下，就開始執行語句了，你寫的語句有沒有語法錯誤，這是接下來MySQL比較關心的點。

那他會怎麼作呢？會先作詞法分析，你的語句有這麼多單詞、空格，MySQL就須要識別每一個字符串所表明的是什麼，是關鍵字，仍是表名，仍是列名等等。

而後就開始語法分析，根據詞法分析的結果，語法分析會判斷你sql的對錯，錯了會提醒你的，而且會提示你哪裏錯了。

分析沒錯以後就進入下一步，優化器。

主要是優化什麼呢？

優化就比較簡單了，由於咱們創建表可能會創建不少索引，優化有一步就是要確認使用哪一個索引，好比使用你的主鍵索引，聯合索引仍是什麼索引更好。

還有就是對執行順序進行優化，條件那麼多，先查哪一個表，仍是先關聯，會出現不少方案，最後由優化器決定選用哪一種方案。

最後就是執行了，執行就交給執行器去作。

第一步可能就是權限的判斷，其實這裏我不肯定的一個點就是，我接觸的公司不少都是自研的線上查詢系統，咱們是不能用Navicat直連線上庫，只能去網頁操做，那表的權限是在MySQL層作的，仍是系統作的，我猜應該是系統層作的，MySQL可能默認就全開放了，只是咱們 不知道ip。

有知道的小夥伴也能夠在公衆號【三太子敖丙】去加我微信跟我說。

執行的時候，就一行一行的去判斷是否知足條件，有索引的執行起來可能就好點，一行行的判斷就像是接口都提早在引擎定義好了，因此他比較快。

數據庫的慢日誌有個rows_examined字段，掃描多少行能夠看到，還有explain也能夠看到執行計劃，咱們掃描了多少行。

能夠小夥子，基礎大體框架仍是瞭解得很清楚的，咱們下次深刻了解下，索引和部分機制。

好的，咱們下次見。

總結

基本上我把MySQL的邏輯架構的東西都簡單聊了一遍，固然你去自信瞭解的話，你會發現其實裏面還有不少細節的，我只是說了一些常見的問題，這仍是阿里丁奇學長的《MySQL實戰》的思路。

我本身在MySQL方面更多的可能就是理論知識了，還作不到深刻了解的地步，你們若是有機會必定要深刻的去學習一下。

絮叨

這應該是我開年的第一篇技術文，原本年前寫了一點索引的東西，可是後面在構思的時候想了想，仍是從數據庫的基礎知識跟你們熟悉起來，再去了解索引會好點。

新年可能會嘗試一些新的文章風格，不必定所有用面試的方式，固然這篇是面試的風格，由於新的風格還沒決定。我還會嘗試着在4月份之後開始以視頻錄製這樣的方式嘗試幾期，你們有什麼意見也能夠在微信上跟我說。

之後絮叨我也放最後，這樣你們閱讀體驗好點，反正有啥直接跟我反饋，寵粉的我，紛紛安排。

你們最近必定穿好衣服不要感冒啥的，雞蛋去看個病，差點嚇尿了，給大家看看他的裝備：

笑死我了，咱們下篇文章見。

很久沒開讚揚了，之後一個月只開一兩次，固定收租哈哈。

三太子敖丙

你知道的越多，你不知道的越多

喜歡做者