題目一
MyISAM和InnoDB的區別，什么時候選擇MyISAM
參考回答
InnoDB是目前MySQL主流版本(5.6、5.7、8.0)默認的存盤引擎，支持事務、外鍵、行級鎖，對于并發條件下要求資料的一致性，適用于對資料準確性要求高的場景，
MyISAM只支持表級鎖、資料排列是按照插入順序，沒有做規則排序，適合應用以查詢和插入為主，只有很少量的更新和洗掉操作，對事務的完整性和并發性要求不是很高的場景，
實際運用
看到很多人在選擇存盤引擎的時候會無腦的選擇InnoDB，這個選擇合理的一點是如果對資料準確性要求沒有那么高，直接用NoSQL就好了，用MySQL就是為了可靠啊，
但是實際作業中，我設計的資料庫中通常都會有幾張MyISAM的資料表，通常用來存盤歷史記錄，與使用InnoDB存盤實時記錄資訊的配合使用，
舉個例子：比如一條物流資訊，在實時的表里存著目前物流的狀態：比如配送中，這條物流在歷史上經過了：正在通知快遞公司取件、XXX已收攬等，這張記錄表基本只有插入和查詢，并且丟失一個中間狀態不影響當前結果，這就很合適用MyISAM，
題目二
簡述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軍規」然后思考每條軍規背后的理論支撐，
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/37901.html
標籤：MySQL
上一篇：MySQL高可用篇之MHA集群