題目一

MyISAM和InnoDB的區(qū)別，什么時候選擇MyISAM

參考回答

InnoDB是目前MySQL主流版本(5.6、5.7、8.0)默認(rèn)的存儲引擎，支持事務(wù)、外鍵、行級鎖，對于并發(fā)條件下要求數(shù)據(jù)的一致性，適用于對數(shù)據(jù)準(zhǔn)確性要求高的場景。

MyISAM只支持表級鎖、數(shù)據(jù)排列是按照插入順序，沒有做規(guī)則排序。適合應(yīng)用以查詢和插入為主，只有很少量的更新和刪除操作，對事務(wù)的完整性和并發(fā)性要求不是很高的場景。

實際運用

看到很多人在選擇存儲引擎的時候會無腦的選擇InnoDB，這個選擇合理的一點是如果對數(shù)據(jù)準(zhǔn)確性要求沒有那么高，直接用NoSQL就好了。用MySQL就是為了可靠啊。

但是實際工作中，我設(shè)計的數(shù)據(jù)庫中通常都會有幾張MyISAM的數(shù)據(jù)表，通常用來存儲歷史記錄，與使用InnoDB存儲實時記錄信息的配合使用。

舉個例子：比如一條物流信息，在實時的表里存著目前物流的狀態(tài)：比如配送中。這條物流在歷史上經(jīng)過了：正在通知快遞公司取件、XXX已收攬等，這張記錄表基本只有插入和查詢，并且丟失一個中間狀態(tài)不影響當(dāng)前結(jié)果，這就很合適用MyISAM。

題目二

簡述MySQL的MVCC多版本并發(fā)控制

參考回答

MVCC是對于事務(wù)隔離級別的讀已提交RC和可重復(fù)讀RR，基于樂觀鎖的實現(xiàn)。在LBCC(基于鎖的并發(fā)控制)RC、RR和串行化分別是通過加行鎖、間隙鎖和表鎖來基于悲觀鎖實現(xiàn)。而樂觀鎖的原理就是在特定的時間點(RC是每次讀時，RR是事務(wù)開始時)生成一個當(dāng)前快照，讀數(shù)據(jù)讀取快照，只在提交時判斷是否有沖突，類似于git的branch和commit。

MVCC會在新開啟一個事務(wù)時，給事務(wù)里包含的每行記錄添加一個當(dāng)前事務(wù)ID和回滾指針。并包含一個Read View，Read View里保存了當(dāng)前活躍的事務(wù)列表，小于這些列表的最近的事務(wù)ID才是可見的。這樣保證了讀到的都是已提交的事務(wù)。

實際運用

MVCC不僅可以用于數(shù)據(jù)庫，也是很常見的一種并發(fā)控制手段。比如使用有限狀態(tài)自動機來控制的訂單狀態(tài)，在更新訂單狀態(tài)的時候先查詢當(dāng)前狀態(tài)，比如當(dāng)前狀態(tài)是訂單未提交，則更新時update XXX set status='訂單已提交' where status='訂單未提交'，如果執(zhí)行這條語句時，status已經(jīng)發(fā)生了改變，這條語句就執(zhí)行失敗了。這樣不通過數(shù)據(jù)庫自身事務(wù)的MVCC，在業(yè)務(wù)邏輯里也實現(xiàn)了MVCC思想的樂觀鎖設(shè)計。

題目三

分布式鎖的實現(xiàn)方式

參考回答

主流有三種

1>基于數(shù)據(jù)庫

1.1>基于數(shù)據(jù)庫主鍵：插入一條數(shù)據(jù)，指定主鍵。如果有兩條插入會主鍵沖突，并發(fā)執(zhí)行失敗

1.2>基于數(shù)據(jù)庫排他鎖：提交一個update事務(wù)，如果這個事務(wù)不提交，其他也對鎖定范圍內(nèi)執(zhí)行update就會阻塞，解決并發(fā)問題

2>基于緩存比如redis的setNX

3>基于zookeeper

實際運用

相信很多人選擇分布式鎖都是選擇第二種，第三種雖然并發(fā)性差一下，如果本來就引入了zk，而沒有緩存，而分布式鎖應(yīng)用量又不那么大，為了減少引入新組件帶來的風(fēng)險和維護成本，也有可能選擇zk。很多人大概認(rèn)為自己沒有用過基于數(shù)據(jù)庫的分布式鎖，實際上在不使用MVCC的時代并不是這樣。

在使用spring進行業(yè)務(wù)開發(fā)的時候，常見的一種場景就是使用spring配置事務(wù)。默認(rèn)級別是Repeatable Read可重復(fù)讀。在這里面如果使用的是LBCC，一進入事務(wù)就加入一個排他鎖，比如insert、update、delete或者select XXX for update。然后做其他的，比如進行一個RPC調(diào)用。這時候一旦出現(xiàn)并發(fā)，只有一個能順利執(zhí)行，其他都會被阻塞。實際上就相當(dāng)于使用了分布式鎖。

題目四

為什么采用B+樹作為索引結(jié)構(gòu)?

參考回答

如果采用Hash表，范圍查找需要全表掃描；如果采用二叉查找樹，由于無法保證平衡，可能退化為鏈表；如果采用平衡二叉樹，通過旋轉(zhuǎn)解決了平衡的問題，但是旋轉(zhuǎn)操作效率太低；如果采用紅黑樹，樹太高，IO次數(shù)多；如果采用普通B樹，節(jié)點要存數(shù)索引和數(shù)據(jù)，一個內(nèi)存頁可存儲的數(shù)據(jù)還是少，另外范圍查找也需要多次IO；

而B+Tree有三個特性：

1>非葉子節(jié)點不存儲data，只存儲索引(冗余)，可以放更多的索引

2>葉子節(jié)點包含所有索引字段

3>葉子節(jié)點用指針鏈接，提高范圍查詢的性能

實際運用

在分布式場景下，我們的業(yè)務(wù)ID都是全局唯一的字符串。如果單純從業(yè)務(wù)上來考慮，用業(yè)務(wù)ID作為數(shù)據(jù)庫的主鍵就足夠了?？梢訢BA往往要求使用整型的自增主鍵作為數(shù)據(jù)庫主鍵，而這個主鍵對業(yè)務(wù)來說就是個浪費，沒有任何業(yè)務(wù)含義。

如果了解了索引的底層結(jié)構(gòu)就不難理解

1>整型比字符串占用更少的空間

2>同時大小比較也很快

3>之所以要自增是每次插入新的記錄，對于葉子節(jié)點來說：記錄會順序的添加到當(dāng)前索引節(jié)點的后續(xù)位置，當(dāng)一頁寫滿，會自動開辟一個新的頁。而如果使用非自增主鍵，就需要插入的時候移動數(shù)據(jù)，甚至目標(biāo)頁面可能已經(jīng)被回寫到磁盤上而從緩存中清掉，此時又要讀回來。分頁操作造成大量的碎片，必須通過優(yōu)化操作重建表并優(yōu)化填充頁面。

題目五

什么叫做覆蓋索引？

參考回答

只需要在一棵輔助索引樹上就可以獲取SQL所需要的所有列數(shù)據(jù)，不需要回表。

實際運用

一些持久層框架比如mybatis的generator插件可以自動生成sql配置文件，這些配置文件往往效率很低。但是剛畢業(yè)的同學(xué)很多都不會去改這個文件，比如只需要個別列的時候會用java的lambda表達式等方式從邏輯上做處理。結(jié)果造成一些性能的問題。

我在根據(jù)一些條件進行范圍查找的時候，如果只需要返回ID或者個別列，會自己去改mybatis的generator自動生成的文件，原因是盡量使用覆蓋索引，較回表速度快。

想驗證是否使用了覆蓋索引，可以用explain執(zhí)行計劃，查看extra字段，如果只顯示Using index說明正確使用了覆蓋索引。如果extra為空或者除了using index還有filesort說明觸發(fā)了回表。

題目六

查詢在什么時候不走索引

參考回答

主要三種情況

1>不滿足走索引的條件，常見的情況有

1.1>不滿足最左匹配原則

1.2>查詢條件使用了函數(shù)

1.3>or操作有一個字段沒有索引

1.4>使用like條件以%開頭

2>走索引效率低于全表掃描，常見的情況有

2.1>查詢條件對null做判斷，而null的值很多

2.2>一個字段區(qū)分度很小，比如性別、狀態(tài)

3>需要回表的查詢結(jié)果集過大，超過了配置的范圍

實際運用

使用索引是為了對查詢做優(yōu)化，要衡量優(yōu)化效果需要數(shù)據(jù)說話。所以需要一些工具來衡量，常用的有：

1>慢查詢?nèi)罩?/span>

開啟慢查詢?nèi)罩?，可以針對慢SQL進行分析看看哪些可以用索引進行優(yōu)化

2>show processlist

show processlist 語句可以查看當(dāng)前正在執(zhí)行的SQL，如果一些SQL執(zhí)行慢，block了其他的SQL，這是個很好的工具

3>show profile分析SQL

使用這個工具可以分析出時間究竟耗費在哪個階段。先查詢是否支持

支持的話，可以用select @@profiling 查看是否開啟，如果結(jié)果為0說明未開啟。需要先set @@profiling=1;

這時候就可以用show profiles查看每一條SQL語句耗費的時間

show profile for query XXID 可以查看具體耗費在哪個階段

4>Trace分析優(yōu)化器的執(zhí)行計劃

使用set optimizer_trace='enabled=on',end_markers_in_json=on;可以打開trace分析，想查看具體的優(yōu)化器執(zhí)行計劃，只要執(zhí)行

select * from `information_schema`.optimizer_trace即可

點擊開每一步都有很詳細的分析

總結(jié)

知識只要學(xué)透了都可以靈活運用。在運用的時候要注意衡量效果。一個常見的誤區(qū)是開發(fā)人員無腦的在MySQL上層加緩存，用來提高效率。但是緩存只適用于讀多寫少的情況，比如在金融交易系統(tǒng)，數(shù)據(jù)讀寫比例1：1。數(shù)據(jù)總是查詢出來下一刻就被更新了，這時候用緩存反而加重系統(tǒng)的負擔(dān)和復(fù)雜性。

這時候，我們可以先利用工具查詢數(shù)據(jù)庫的讀寫比例。比如show global status like 'Com_______' 這個SQL可以查看select、update、insert、delete都被執(zhí)行了多少次。

或者show global status like 'Innodb_row_%' 除了查看Innodb的讀寫情況，還可以查看鎖的情況。

思考

請網(wǎng)上搜索一下「58Mysql軍規(guī)」然后思考每條軍規(guī)背后的理論支撐。