題目一java
MyISAM和InnoDB的區別,何時選擇MyISAMgit
參考回答redis
InnoDB是目前MySQL主流版本(5.六、5.七、8.0)默認的存儲引擎,支持事務、外鍵、行級鎖,對於併發條件下要求數據的一致性,適用於對數據準確性要求高的場景。spring
MyISAM只支持表級鎖、數據排列是按照插入順序,沒有作規則排序。適合應用以查詢和插入爲主,只有不多量的更新和刪除操做,對事務的完整性和併發性要求不是很高的場景。sql
實際運用數據庫
看到不少人在選擇存儲引擎的時候會無腦的選擇InnoDB,這個選擇合理的一點是若是對數據準確性要求沒有那麼高,直接用NoSQL就行了。用MySQL就是爲了可靠啊。json
可是實際工做中,我設計的數據庫中一般都會有幾張MyISAM的數據表,一般用來存儲歷史記錄,與使用InnoDB存儲實時記錄信息的配合使用。緩存
舉個例子:好比一條物流信息,在實時的表裏存着目前物流的狀態:好比配送中。這條物流在歷史上通過了:正在通知快遞公司取件、XXX已收攬等,這張記錄表基本只有插入和查詢,而且丟失一箇中間狀態不影響當前結果,這就很合適用MyISAM。mybatis
題目二併發
簡述MySQL的MVCC多版本併發控制
參考回答
MVCC是對於事務隔離級別的讀已提交RC和可重複讀RR,基於樂觀鎖的實現。在LBCC(基於鎖的併發控制)RC、RR和串行化分別是經過加行鎖、間隙鎖和表鎖來基於悲觀鎖實現。而樂觀鎖的原理就是在特定的時間點(RC是每次讀時,RR是事務開始時)生成一個當前快照,讀數據讀取快照,只在提交時判斷是否有衝突,相似於git的branch和commit。
MVCC會在新開啓一個事務時,給事務裏包含的每行記錄添加一個當前事務ID和回滾指針。幷包含一個Read View,Read View裏保存了當前活躍的事務列表,小於這些列表的最近的事務ID纔是可見的。這樣保證了讀到的都是已提交的事務。
實際運用
MVCC不只能夠用於數據庫,也是很常見的一種併發控制手段。好比使用有限狀態自動機來控制的訂單狀態,在更新訂單狀態的時候先查詢當前狀態,好比當前狀態是訂單未提交,則更新時update XXX set status='訂單已提交' where status='訂單未提交',若是執行這條語句時,status已經發生了改變,這條語句就執行失敗了。這樣不經過數據庫自身事務的MVCC,在業務邏輯裏也實現了MVCC思想的樂觀鎖設計。
題目三
分佈式鎖的實現方式
參考回答
主流有三種
1>基於數據庫
1.1>基於數據庫主鍵:插入一條數據,指定主鍵。若是有兩條插入會主鍵衝突,併發執行失敗
1.2>基於數據庫排他鎖:提交一個update事務,若是這個事務不提交,其餘也對鎖定範圍內執行update就會阻塞,解決併發問題
2>基於緩存好比redis的setNX
3>基於zookeeper
實際運用
相信不少人選擇分佈式鎖都是選擇第二種,第三種雖然併發性差一下,若是原本就引入了zk,而沒有緩存,而分佈式鎖應用量又不那麼大,爲了減小引入新組件帶來的風險和維護成本,也有可能選擇zk。不少人大概認爲本身沒有用過基於數據庫的分佈式鎖,實際上在不使用MVCC的時代並非這樣。
在使用spring進行業務開發的時候,常見的一種場景就是使用spring配置事務。默認級別是Repeatable Read可重複讀。在這裏面若是使用的是LBCC,一進入事務就加入一個排他鎖,好比insert、update、delete或者select XXX for update。而後作其餘的,好比進行一個RPC調用。這時候一旦出現併發,只有一個能順利執行,其餘都會被阻塞。實際上就至關於使用了分佈式鎖。
題目四
爲何採用B+樹做爲索引結構?
參考回答
若是採用Hash表,範圍查找須要全表掃描;若是採用二叉查找樹,因爲沒法保證平衡,可能退化爲鏈表;若是採用平衡二叉樹,經過旋轉解決了平衡的問題,可是旋轉操做效率過低;若是採用紅黑樹,樹過高,IO次數多;若是採用普通B樹,節點要存數索引和數據,一個內存頁可存儲的數據仍是少,另外範圍查找也須要屢次IO;
而B+Tree有三個特性:
1>非葉子節點不存儲data,只存儲索引(冗餘),能夠放更多的索引
2>葉子節點包含全部索引字段
3>葉子節點用指針連接,提升範圍查詢的性能
實際運用
在分佈式場景下,咱們的業務ID都是全局惟一的字符串。若是單純從業務上來考慮,用業務ID做爲數據庫的主鍵就足夠了。能夠DBA每每要求使用整型的自增主鍵做爲數據庫主鍵,而這個主鍵對業務來講就是個浪費,沒有任何業務含義。
若是瞭解了索引的底層結構就不難理解
1>整型比字符串佔用更少的空間
2>同時大小比較也很快
3>之因此要自增是每次插入新的記錄,對於葉子節點來講:記錄會順序的添加到當前索引節點的後續位置,當一頁寫滿,會自動開闢一個新的頁。而若是使用非自增主鍵,就須要插入的時候移動數據,甚至目標頁面可能已經被回寫到磁盤上而從緩存中清掉,此時又要讀回來。分頁操做形成大量的碎片,必須經過優化操做重建表並優化填充頁面。
題目五
什麼叫作覆蓋索引?
參考回答
只須要在一棵輔助索引樹上就能夠獲取SQL所須要的全部列數據,不須要回表。
實際運用
一些持久層框架好比mybatis的generator插件能夠自動生成sql配置文件,這些配置文件每每效率很低。可是剛畢業的同窗不少都不會去改這個文件,好比只須要個別列的時候會用java的lambda表達式等方式從邏輯上作處理。結果形成一些性能的問題。
我在根據一些條件進行範圍查找的時候,若是隻須要返回ID或者個別列,會本身去改mybatis的generator自動生成的文件,緣由是儘可能使用覆蓋索引,較回錶速度快。
想驗證是否使用了覆蓋索引,能夠用explain執行計劃,查看extra字段,若是隻顯示Using index說明正確使用了覆蓋索引。若是extra爲空或者除了using index還有filesort說明觸發了回表。
題目六
查詢在何時不走索引
參考回答
主要三種狀況
1>不知足走索引的條件,常見的狀況有
1.1>不知足最左匹配原則
1.2>查詢條件使用了函數
1.3>or操做有一個字段沒有索引
1.4>使用like條件以%開頭
2>走索引效率低於全表掃描,常見的狀況有
2.1>查詢條件對null作判斷,而null的值不少
2.2>一個字段區分度很小,好比性別、狀態
3>須要回表的查詢結果集過大,超過了配置的範圍
實際運用
使用索引是爲了對查詢作優化,要衡量優化效果須要數聽說話。因此須要一些工具來衡量,經常使用的有:
1>慢查詢日誌
開啓慢查詢日誌,能夠針對慢SQL進行分析看看哪些能夠用索引進行優化
2>show processlist
show processlist 語句能夠查看當前正在執行的SQL,若是一些SQL執行慢,block了其餘的SQL,這是個很好的工具
3>show profile分析SQL
使用這個工具能夠分析出時間究竟耗費在哪一個階段。先查詢是否支持
支持的話,能夠用select @@profiling 查看是否開啓,若是結果爲0說明未開啓。須要先set @@profiling=1;
這時候就能夠用show profiles查看每一條SQL語句耗費的時間
show profile for query XXID 能夠查看具體耗費在哪一個階段
4>Trace分析優化器的執行計劃
使用set optimizer_trace='enabled=on',end_markers_in_json=on;能夠打開trace分析,想查看具體的優化器執行計劃,只要執行
select * from `information_schema`.optimizer_trace便可
點擊開每一步都有很詳細的分析
總結
知識只要學透了均可以靈活運用。在運用的時候要注意衡量效果。一個常見的誤區是開發人員無腦的在MySQL上層加緩存,用來提升效率。可是緩存只適用於讀多寫少的狀況,好比在金融交易系統,數據讀寫比例1:1。數據老是查詢出來下一刻就被更新了,這時候用緩存反而加劇系統的負擔和複雜性。
這時候,咱們能夠先利用工具查詢數據庫的讀寫比例。好比show global status like 'Com_______' 這個SQL能夠查看select、update、insert、delete都被執行了多少次。
或者show global status like 'Innodb_row_%' 除了查看Innodb的讀寫狀況,還能夠查看鎖的狀況。
思考
請網上搜索一下「58Mysql軍規」而後思考每條軍規背後的理論支撐。