1.什么是聚集索引和非聚集索引

簡單來說，聚集索引就是基于主鍵創(chuàng)建的索引，除了主鍵索引以外的其他索引，稱為非聚集索引，也叫做二級索引。

• 由于在InnoDB引擎里面，一張表的數(shù)據(jù)對應(yīng)的物理文件本身就是按照B+樹來組織的一種索引結(jié)構(gòu)，而聚集索引就是按照每張表的主鍵來構(gòu)建一顆B+樹，然后葉子節(jié)點里面存儲了這個表的每一行數(shù)據(jù)記錄。
• 所以基于InnoDB這樣的特性，聚集索引并不僅僅是一種索引類型，還代表著一種數(shù)據(jù)的存儲方式。
• 同時也意味著每個表里面必須要有一個主鍵，如果沒有主鍵，InnoDB會默認(rèn)選擇或者添加一個隱藏列作為主鍵索引來存儲這個表的數(shù)據(jù)行。一般情況是建議使用自增id作為主鍵，這樣的話id本身具有連續(xù)性使得對應(yīng)的數(shù)據(jù)也會按照順序存儲在磁盤上，寫入性能和檢索性能都很高。否則，如果使用uuid這種隨機id，那么在頻繁插入數(shù)據(jù)的時候，就會導(dǎo)致隨機磁盤IO，從而導(dǎo)致性能較低。
• 需要注意的是，InnoDB里面只能存在一個聚集索引，原因很簡單，如果存在多個聚集索引，那么意味著這個表里面的數(shù)據(jù)存在多個副本，造成磁盤空間的浪費，以及數(shù)據(jù)維護的困難。
• （如圖）由于在InnoDB里面，主鍵索引表示的是一種數(shù)據(jù)存儲結(jié)構(gòu)，所以如果是基于非聚集索引來查詢一條完整的記錄，最終還是需要訪問主鍵索引來檢索。

2.請你簡單說一下Mysql的事務(wù)隔離級別

事務(wù)隔離級別，是為了解決多個并行事務(wù)競爭導(dǎo)致的數(shù)據(jù)安全問題的一種規(guī)范。

具體來說，多個事務(wù)競爭可能會產(chǎn)生三種不同的現(xiàn)象。

1.(如圖）假設(shè)有兩個事務(wù)T1/T2同時在執(zhí)行，T1事務(wù)有可能會讀取到T2事務(wù)未提交的數(shù)據(jù)，但是未提交的事務(wù)T2可能會回滾，也就導(dǎo)致了T1事務(wù)讀取到最終不一定存在的數(shù)據(jù)產(chǎn)生臟讀的現(xiàn)象。

2.（如圖）假設(shè)有兩個事務(wù)T1/T2同時執(zhí)行，事務(wù)T1在不同的時刻讀取同一行數(shù)據(jù)的時候結(jié)果可能不一樣，從而導(dǎo)致不可重復(fù)讀的問題。

3.（如圖），假設(shè)有兩個事務(wù)T1/T2同時執(zhí)行，事務(wù)T1執(zhí)行范圍查詢或者范圍修改的過程中，事務(wù)T2插入了一條屬于事務(wù)T1范圍內(nèi)的數(shù)據(jù)并且提交了，這時候在事務(wù)T1查詢發(fā)現(xiàn)多出來了一條數(shù)據(jù)，或者在T1事務(wù)發(fā)現(xiàn)這條數(shù)據(jù)沒有被修改，看起來像是產(chǎn)生了幻覺，這種現(xiàn)象稱為幻讀。

而這三種現(xiàn)象在實際應(yīng)用中，可能有些場景不能接受某些現(xiàn)象的存在，所以在SQL標(biāo)準(zhǔn)中定義了四種隔離級別，分別是：

• 讀未提交，在這種隔離級別下，可能會產(chǎn)生臟讀、不可重復(fù)讀、幻讀。
• 讀已提交（RC)，在這種隔離級別下，可能會產(chǎn)生不可重復(fù)讀和幻讀。
• 可重復(fù)讀（RR），在這種隔離級別下，可能會產(chǎn)生幻讀
• 串行化，在這種隔離級別下，多個并行事務(wù)串行化執(zhí)行，不會產(chǎn)生安全性問題。

這四種隔離級別里面，只有串行化解決了全部的問題，但也意味著這種隔離級別的性能是最低的。

3.MVCC的理解

對于MVCC的理解，我覺得可以先從數(shù)據(jù)庫的三種并發(fā)場景說起：

第一種：讀讀

就是線程A與線程B同時在進行讀操作，這種情況下不會出現(xiàn)任何并發(fā)問題。

第二種：讀寫  

就是線程A與線程B在同一時刻分別進行讀和寫操作。

這種情況下，可能會對數(shù)據(jù)庫中的數(shù)據(jù)造成以下問題：

• 事物隔離性問題，
• 出現(xiàn)臟讀，幻讀，不可重復(fù)讀的問題

第三種：寫寫

就是線程A與線程B同時進行寫操作

這種情況下可能會存在數(shù)據(jù)更新丟失的問題。

而MVCC就是為了解決事務(wù)操作中并發(fā)安全性問題的無鎖并發(fā)控制技術(shù)全稱為Multi-Version Concurrency Control ，也就是多版本并發(fā)控制。它是通過數(shù)據(jù)庫記錄中的隱式字段，undo日志 ，Read View 來實現(xiàn)的。

 MVCC主要解決了三個問題

• 第一個是：通過MVCC 可以解決讀寫并發(fā)阻塞問題從而提升數(shù)據(jù)并發(fā)處理能力
• 第二個是：MVCC 采用了樂觀鎖的方式實現(xiàn)，降低了死鎖的概率
• 第三個是：解決了一致性讀的問題也就是事務(wù)啟動時根據(jù)某個條件讀取到的數(shù)據(jù)，直到事務(wù)結(jié)束時，再次執(zhí)行相同條件，還是讀到同一份數(shù)據(jù)，不會發(fā)生變化。

而我們在使用MVCC時一般會根據(jù)業(yè)務(wù)場景來選擇組合搭配樂觀鎖或悲觀鎖。

這兩個組合中，MVCC用來解決讀寫沖突，樂觀鎖或者悲觀鎖解決寫寫沖突從而最大程度的提高數(shù)據(jù)庫并發(fā)性能。

4.日常工作中是怎么優(yōu)化SQL

• 加索引，增加索引是一種簡單高效的手段，但是需要選擇合適的列，同時避免導(dǎo)致索引失效的操作，比如like、函數(shù)等。
• 避免返回不必要的數(shù)據(jù)列，減少返回的數(shù)據(jù)列可以增加查詢的效率。
• 根據(jù)查詢分析器適當(dāng)優(yōu)化SQL的結(jié)構(gòu)，比如是否走全表掃描、避免子查詢等
• 分庫分表，在單表數(shù)據(jù)量較大或者并發(fā)連接數(shù)過高的情況下，通過這種方式可以有效提升查詢效率
• 讀寫分離，針對讀多寫少的場景，這樣可以保證寫操作的數(shù)據(jù)庫承受更小的壓力，也可以緩解獨占鎖和共享鎖的競爭。

5.Mysql為什么使用B+Tree作為索引結(jié)構(gòu)

首先，常規(guī)的數(shù)據(jù)庫存儲引擎，一般都是采用B樹或者B+樹來實現(xiàn)索引的存儲。

（如圖）因為B樹是一種多路平衡樹，用這種存儲結(jié)構(gòu)來存儲大量數(shù)據(jù)，它的整個高度會相比二叉樹來說，會矮很多。

而對于數(shù)據(jù)庫來說，所有的數(shù)據(jù)必然都是存儲在磁盤上的，而磁盤IO的效率實際上是很低的，特別是在隨機磁盤IO的情況下效率更低。

所以樹的高度能夠決定磁盤IO的次數(shù)，磁盤IO次數(shù)越少，對于性能的提升就越大，這也是為什么采用B樹作為索引存儲結(jié)構(gòu)的原因。

（如圖）但是在Mysql的InnoDB存儲引擎里面，它用了一種增強的B樹結(jié)構(gòu)，也就是B+樹來作為索引和數(shù)據(jù)的存儲結(jié)構(gòu)。

相比較于B樹結(jié)構(gòu)，B+樹做了幾個方面的優(yōu)化。

• B+樹的所有數(shù)據(jù)都存儲在葉子節(jié)點，非葉子節(jié)點只存儲索引。
• 葉子節(jié)點中的數(shù)據(jù)使用雙向鏈表的方式進行關(guān)聯(lián)。

使用B+樹來實現(xiàn)索引的原因，我認(rèn)為有幾個方面。

• B+樹非葉子節(jié)點不存儲數(shù)據(jù)，所以每一層能夠存儲的索引數(shù)量會增加，意味著B+樹在層高相同的情況下存儲的數(shù)據(jù)量要比B樹要多，使得磁盤IO次數(shù)更少。
• 在Mysql里面，范圍查詢是一個比較常用的操作，而B+樹的所有存儲在葉子節(jié)點的數(shù)據(jù)使用了雙向鏈表來關(guān)聯(lián)，所以在查詢的時候只需查兩個節(jié)點進行遍歷就行，而B樹需要獲取所有節(jié)點，所以B+樹在范圍查詢上效率更高。
• 在數(shù)據(jù)檢索方面，由于所有的數(shù)據(jù)都存儲在葉子節(jié)點，所以B+樹的IO次數(shù)會更加穩(wěn)定一些。
• 因為葉子節(jié)點存儲所有數(shù)據(jù)，所以B+樹的全局掃描能力更強一些，因為它只需要掃描葉子節(jié)點。但是B樹需要遍歷整個樹。

另外，基于B+樹這樣一種結(jié)構(gòu)，如果采用自增的整型數(shù)據(jù)作為主鍵，還能更好的避免增加數(shù)據(jù)的時候，帶來葉子節(jié)點分裂導(dǎo)致的大量運算的問題。

總結(jié)：

技術(shù)方案的選型，更多的是去解決當(dāng)前場景下的特定問題，并不一定是說B+樹就是最好的選擇，就像MongoDB里面采用B樹結(jié)構(gòu)，本質(zhì)上來說，其實是關(guān)系型數(shù)據(jù)庫和非關(guān)系型數(shù)據(jù)庫的差異。

6.Mysql索引的優(yōu)點和缺點？ 

索引，是一種能夠幫助Mysql高效從磁盤上檢索數(shù)據(jù)的一種數(shù)據(jù)結(jié)構(gòu)。

在Mysql中的InnoDB引擎中，采用了B+樹的結(jié)構(gòu)來實現(xiàn)索引和數(shù)據(jù)的存儲

Mysql里面的索引的優(yōu)點有很多

• 通過B+樹的結(jié)構(gòu)來存儲數(shù)據(jù)，可以大大減少數(shù)據(jù)檢索時的磁盤IO次數(shù)，從而提升數(shù)據(jù)查詢的性能
• B+樹索引在進行范圍查找的時候，只需要找到起始節(jié)點，然后基于葉子節(jié)點的鏈表結(jié)構(gòu)往下讀取即可，查詢效率較高。
• 通過唯一索引約束，可以保證數(shù)據(jù)表中每一行數(shù)據(jù)的唯一性

當(dāng)然，索引的不合理使用，也會有帶來很多的缺點。

• 數(shù)據(jù)的增加、修改、刪除，需要涉及到索引的維護，當(dāng)數(shù)據(jù)量較大的情況下，索引的維護會帶來較大的性能開銷。
• 一個表中允許存在一個聚簇索引和多個非聚簇索引，但是索引數(shù)不能創(chuàng)建太多，否則造成的索引維護成本過高。
• 創(chuàng)建索引的時候，需要考慮到索引字段值的分散性，如果字段的重復(fù)數(shù)據(jù)過多，創(chuàng)建索引反而會帶來性能降低。

7.索引什么時候失效？

1.在索引列上做運算，比如使用函數(shù)，Mysql在生成執(zhí)行計劃的時候，它是根據(jù)統(tǒng)計信息來判斷是否要使用索引的。

        而在索引列上加函數(shù)運算，導(dǎo)致Mysql無法識別索引列，也就不會再走索引了。

        不過從Mysql8開始，增加了函數(shù)索引可以解決這個問題。

2.在一個由多列構(gòu)成的組合索引中，需要按照最左匹配法則，也就是從索引的最左列開始順序檢索，否則不會走索引。

在組合索引中，索引的存儲結(jié)構(gòu)是按照索引列的順序來存儲的，因此在sql中也需要按照這個順序才能進行逐一匹配。

否則InnoDB無法識別索引導(dǎo)致索引失效。

3.當(dāng)索引列存在隱式轉(zhuǎn)化的時候， 比如索引列是字符串類型，但是在sql查詢中沒有使用引號。

那么Mysql會自動進行類型轉(zhuǎn)化，從而導(dǎo)致索引失效

4.在索引列使用不等于號、not查詢的時候，由于索引數(shù)據(jù)的檢索效率非常低，因此Mysql引擎會判斷不走索引。

5.使用like通配符匹配后綴%xxx的時候，由于這種方式不符合索引的最左匹配原則，所以也不會走索引。

但是反過來，如果通配符匹配的是前綴xxx%，符合最左匹配，也會走索引。

6.使用or連接查詢的時候，or語句前后沒有同時使用索引，那么索引會失效。只有or左右查詢字段都是索引列的時候，才會生效。

除了這些場景以外，對于多表連接查詢的場景中，連接順序也會影響索引的使用。

不過最終是否走索引，我們可以使用explain命令來查看sql的執(zhí)行計劃，然后針對性的進行調(diào)優(yōu)即可。

8. InnoDB 與MyISAM 有什么區(qū)別

• 事務(wù)支持不同，InnoDB 支持事務(wù)處理，而 MyISAM 不支持。
• 并發(fā)處理不同：InnoDB 支持行級鎖，而 MyISAM 支持表級鎖
• 外鍵支持不同：InnoDB 支持外鍵約束，而 MyISAM 不支持
• 性能上存在差異：MyISAM 的讀取速度比 InnoDB 快，但是在高并發(fā)環(huán)境下，InnoDB 的性能更好。這是因為 InnoDB 支持行級鎖和事務(wù)處理，而 MyISAM 不支持。

所以，如果是讀多寫少的情況下，使用MyISAM引擎會更合適

5.數(shù)據(jù)安全不同：InnoDB 支持崩潰恢復(fù)和數(shù)據(jù)恢復(fù)，而 MyISAM 不支持。如果 MySQL 崩潰了或者發(fā)生意外故障，InnoDB 可以通過恢復(fù)日志來恢復(fù)數(shù)據(jù)。

9.為什么 SQL 語句不要過多的 join？

• 性能問題：每個 join 操作都需要對兩個或多個表進行連接操作，這個操作需要消耗大量的計算資源和時間，如果 join 操作過多，會導(dǎo)致 SQL 的執(zhí)行效率降低，從而影響整個系統(tǒng)的性能。
• 可讀性和維護性問題：join 操作會使 SQL 語句變得復(fù)雜，難以理解和維護，特別是當(dāng) join 操作涉及到多個表的時候，SQL 語句的復(fù)雜度會呈現(xiàn)指數(shù)級增長，給代碼的可讀性和可維護性帶來挑戰(zhàn)。

10.binlog和redolog有什么區(qū)別？

binlog和redolog都是Mysql里面用來記錄數(shù)據(jù)庫數(shù)據(jù)變更操作的日志。

｛如圖｝其中binlog主要用來做數(shù)據(jù)備份、數(shù)據(jù)恢復(fù)和數(shù)據(jù)同步，大家初步接觸這個概念 ，應(yīng)該是在Mysql的主從數(shù)據(jù)同步的場景中，master節(jié)點的數(shù)據(jù)變更，會寫入到binlog中，然后再把binlog中的數(shù)據(jù)通過網(wǎng)絡(luò)傳輸給slave節(jié)點，實現(xiàn)數(shù)據(jù)同步。

問題答案

binlog和redolog的區(qū)別有很多，我可以簡單總結(jié)三個點

• 使用場景不同，binlog主要用來做數(shù)據(jù)備份、數(shù)據(jù)恢復(fù)、以及主從集群的數(shù)據(jù)同步； Redo Log主要用來實現(xiàn)Mysql數(shù)據(jù)庫的事務(wù)恢復(fù)，保證事務(wù)的ACID特性。當(dāng)數(shù)據(jù)庫出現(xiàn)崩潰的時候，Redo Log可以把未提交的事務(wù)回滾，把已提交的事務(wù)進行持久化，從而保證數(shù)據(jù)的一致性和持久性。
• 記錄的信息不同，binlog是記錄數(shù)據(jù)庫的邏輯變化，它提供了三種日志格式分別是statement，row以及mixed；

redo log記錄的是物理變化，也就是數(shù)據(jù)頁的變化結(jié)果。

• 記錄的時機不同， binlog是在執(zhí)行SQL語句的時候，在主線程中生成邏輯變化寫入到磁盤中，所以它是語句級別的記錄方式； RedoLog是在InnoDB存儲引擎層面的操作，它是在Mysql后臺線程中生成并寫入到磁盤中的，所以它是事務(wù)級別的記錄方式，一個事務(wù)操作完成以后才會被寫入到redo log中。

總結(jié) 

到此這篇關(guān)于MySQL最常問的十道面試題的文章就介紹到這了,更多相關(guān)MySQL最常問面試題內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論