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

簡(jiǎn)單來(lái)說(shuō)，聚集索引就是基于主鍵創(chuàng)建的索引，除了主鍵索引以外的其他索引，稱(chēng)為非聚集索引，也叫做二級(jí)索引。

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

2.請(qǐng)你簡(jiǎn)單說(shuō)一下Mysql的事務(wù)隔離級(jí)別

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

具體來(lái)說(shuō)，多個(gè)事務(wù)競(jìng)爭(zhēng)可能會(huì)產(chǎn)生三種不同的現(xiàn)象。

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

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

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

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

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

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

3.MVCC的理解

對(duì)于MVCC的理解，我覺(jué)得可以先從數(shù)據(jù)庫(kù)的三種并發(fā)場(chǎng)景說(shuō)起：

第一種：讀讀

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

第二種：讀寫(xiě)  

就是線(xiàn)程A與線(xiàn)程B在同一時(shí)刻分別進(jìn)行讀和寫(xiě)操作。

這種情況下，可能會(huì)對(duì)數(shù)據(jù)庫(kù)中的數(shù)據(jù)造成以下問(wèn)題：

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

第三種：寫(xiě)寫(xiě)

就是線(xiàn)程A與線(xiàn)程B同時(shí)進(jìn)行寫(xiě)操作

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

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

 MVCC主要解決了三個(gè)問(wèn)題

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

而我們?cè)谑褂肕VCC時(shí)一般會(huì)根據(jù)業(yè)務(wù)場(chǎng)景來(lái)選擇組合搭配樂(lè)觀(guān)鎖或悲觀(guān)鎖。

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

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

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

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

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

（如圖）因?yàn)锽樹(shù)是一種多路平衡樹(shù)，用這種存儲(chǔ)結(jié)構(gòu)來(lái)存儲(chǔ)大量數(shù)據(jù)，它的整個(gè)高度會(huì)相比二叉樹(shù)來(lái)說(shuō)，會(huì)矮很多。

而對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，所有的數(shù)據(jù)必然都是存儲(chǔ)在磁盤(pán)上的，而磁盤(pán)IO的效率實(shí)際上是很低的，特別是在隨機(jī)磁盤(pán)IO的情況下效率更低。

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

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

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

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

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

• B+樹(shù)非葉子節(jié)點(diǎn)不存儲(chǔ)數(shù)據(jù)，所以每一層能夠存儲(chǔ)的索引數(shù)量會(huì)增加，意味著B(niǎo)+樹(shù)在層高相同的情況下存儲(chǔ)的數(shù)據(jù)量要比B樹(shù)要多，使得磁盤(pán)IO次數(shù)更少。
• 在Mysql里面，范圍查詢(xún)是一個(gè)比較常用的操作，而B(niǎo)+樹(shù)的所有存儲(chǔ)在葉子節(jié)點(diǎn)的數(shù)據(jù)使用了雙向鏈表來(lái)關(guān)聯(lián)，所以在查詢(xún)的時(shí)候只需查兩個(gè)節(jié)點(diǎn)進(jìn)行遍歷就行，而B(niǎo)樹(shù)需要獲取所有節(jié)點(diǎn)，所以B+樹(shù)在范圍查詢(xún)上效率更高。
• 在數(shù)據(jù)檢索方面，由于所有的數(shù)據(jù)都存儲(chǔ)在葉子節(jié)點(diǎn)，所以B+樹(shù)的IO次數(shù)會(huì)更加穩(wěn)定一些。
• 因?yàn)槿~子節(jié)點(diǎn)存儲(chǔ)所有數(shù)據(jù)，所以B+樹(shù)的全局掃描能力更強(qiáng)一些，因?yàn)樗恍枰獟呙枞~子節(jié)點(diǎn)。但是B樹(shù)需要遍歷整個(gè)樹(shù)。

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

總結(jié)：

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

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

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

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

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

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

當(dāng)然，索引的不合理使用，也會(huì)有帶來(lái)很多的缺點(diǎn)。

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

7.索引什么時(shí)候失效？

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

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

        不過(guò)從Mysql8開(kāi)始，增加了函數(shù)索引可以解決這個(gè)問(wèn)題。

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

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

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

3.當(dāng)索引列存在隱式轉(zhuǎn)化的時(shí)候， 比如索引列是字符串類(lèi)型，但是在sql查詢(xún)中沒(méi)有使用引號(hào)。

那么Mysql會(huì)自動(dòng)進(jìn)行類(lèi)型轉(zhuǎn)化，從而導(dǎo)致索引失效

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

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

但是反過(guò)來(lái)，如果通配符匹配的是前綴xxx%，符合最左匹配，也會(huì)走索引。

6.使用or連接查詢(xún)的時(shí)候，or語(yǔ)句前后沒(méi)有同時(shí)使用索引，那么索引會(huì)失效。只有or左右查詢(xún)字段都是索引列的時(shí)候，才會(huì)生效。

除了這些場(chǎng)景以外，對(duì)于多表連接查詢(xún)的場(chǎng)景中，連接順序也會(huì)影響索引的使用。

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

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

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

所以，如果是讀多寫(xiě)少的情況下，使用MyISAM引擎會(huì)更合適

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

9.為什么 SQL 語(yǔ)句不要過(guò)多的 join？

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

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

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

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

問(wèn)題答案

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

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

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

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

總結(jié) 

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

最新評(píng)論