在之前好多章節(jié)中，已經(jīng)把語言類和計(jì)算機(jī)網(wǎng)絡(luò)做了相關(guān)總結(jié)，后面我會(huì)專門出一章來總結(jié)一下之前的筆記，給大家捋一捋到底該怎么去看這些文章。

雖然這會(huì)兒總結(jié)出來的都是很零散的知識，可能看的時(shí)候沒有什么頭緒，也不知道從什么地方看起，但是你也可以去合集找找相關(guān)的專題，都很全，文章字?jǐn)?shù)可能有點(diǎn)多，學(xué)習(xí)的時(shí)候還是需要點(diǎn)耐心的哈。

作為后端開發(fā)工程師，數(shù)據(jù)庫是怎么也繞不過去的一個(gè)坎，相信你們在學(xué)校的時(shí)候也學(xué)過什么SQLserver或者其它數(shù)據(jù)庫，最多的可能就是練習(xí)寫寫SQL語句類的東西。

MySQL作為當(dāng)下最流行的關(guān)系型數(shù)據(jù)庫之一，也是面試中的“熱門”，面試官不僅會(huì)考察你對SQL語句的熟練程度，也會(huì)對它的一個(gè)底層原理做非常多的考察。只要你簡歷上寫就必問，要是沒寫，也會(huì)問你會(huì)不會(huì)數(shù)據(jù)庫。所以你自己體會(huì)它的重要性。

今天這節(jié)內(nèi)容是對MySQL數(shù)據(jù)庫在面試過程中遇到的一些高頻問題做一個(gè)總結(jié)，可能你看完這篇文章就不需要專門去準(zhǔn)備數(shù)據(jù)庫相關(guān)的知識了。里面的內(nèi)容大多是我在面試過程中遇到的，大家都知道近兩年是非常非常卷的，一個(gè)崗位可能有無數(shù)個(gè)候選人在面試，如果你想脫穎而出，那么就需要非常強(qiáng)的基礎(chǔ)作為你的踏板。OK，不浪費(fèi)時(shí)間說這么多了，大家認(rèn)真看吧。

一、數(shù)據(jù)庫基礎(chǔ)

1、數(shù)據(jù)庫索引為什么要B+樹

數(shù)據(jù)庫的索引是使用B+樹來實(shí)現(xiàn)的。

那為什么要用B+樹，為什么不用紅黑樹和B樹？

B+樹是一種特殊的平衡多路樹，是B樹的優(yōu)化改進(jìn)版本，它把所有的數(shù)據(jù)都存放在葉節(jié)點(diǎn)上，中間節(jié)點(diǎn)保存的是索引。這樣一來相對于B樹來說，減少了數(shù)據(jù)對中間節(jié)點(diǎn)的空間占用，使得中間節(jié)點(diǎn)可以存放更多的指針，使得樹變得更矮，深度更小，從而減少查詢的磁盤IO次數(shù)，提高查詢效率。另一個(gè)是由于葉節(jié)點(diǎn)之間有指針連接，所以可以進(jìn)行范圍查詢，方便區(qū)間訪問。

而紅黑樹是二叉的，它的深度相對B+樹來說更大，更大的深度意味著查找次數(shù)更多，更頻繁的磁盤IO，所以紅黑樹更適合在內(nèi)存中進(jìn)行查找。

B+樹更適合操作系統(tǒng)文件索引和數(shù)據(jù)索引的原因：

1. B+樹磁盤讀寫代價(jià)更低，B+樹的內(nèi)部節(jié)點(diǎn)沒有指向關(guān)鍵字具體信息的指針。因此內(nèi)部節(jié)點(diǎn)相對于B-樹更小，如果把所有同一內(nèi)部節(jié)點(diǎn)的關(guān)鍵字放入同一塊磁盤當(dāng)中。盤所能容納的關(guān)鍵字?jǐn)?shù)量也就更多。一次性讀入內(nèi)存中需要查找的關(guān)鍵字也就越多，相對的IO讀寫次數(shù)就有所降低。
2. B+樹查詢效率更加穩(wěn)定。由于非終結(jié)點(diǎn)并不是最終指向文件內(nèi)容的節(jié)點(diǎn)，而只是葉子節(jié)點(diǎn)中關(guān)鍵字的索引。所以任何關(guān)鍵字的查找必須走一條從根節(jié)點(diǎn)到葉子節(jié)點(diǎn)的路徑。所有的關(guān)鍵字查詢路徑長度都是相同的，導(dǎo)致了每一個(gè)數(shù)據(jù)查詢的效率相當(dāng)。

2、MYSQL的引擎對比

2.1、MySQL引擎

MySQL中的數(shù)據(jù)用各種不同的技術(shù)存儲在文件（或者內(nèi)存）中。這些技術(shù)中的每一種技術(shù)都使用不同的存儲機(jī)制、索引技巧、鎖定水平并且最終提供廣泛的不同的功能和能力。通過選擇不同的技術(shù)，你能夠獲得額外的速度或者功能，從而改善你的應(yīng)用的整體功能。

數(shù)據(jù)庫引擎是用于存儲、處理和保護(hù)數(shù)據(jù)的核心服務(wù)。利用數(shù)據(jù)庫引擎可控制訪問權(quán)限并快速處理事務(wù)，從而滿足企業(yè)內(nèi)大多數(shù)需要處理大量數(shù)據(jù)的應(yīng)用程序的要求。使用數(shù)據(jù)庫引擎創(chuàng)建用于聯(lián)機(jī)事務(wù)處理或聯(lián)機(jī)分析處理數(shù)據(jù)的關(guān)系數(shù)據(jù)庫。這包括創(chuàng)建用于存儲數(shù)據(jù)的表和用于查看、管理和保護(hù)數(shù)據(jù)安全的數(shù)據(jù)庫對象（如索引、視圖和存儲過程）。

MySQL存儲引擎主要有：MyIsam、InnoDB、Memory、Blackhole、CSV、Performance_Schema、Archive、Federated、Mrg_Myisam。

但是最常用的是InnoDB和Mylsam。

2.2、InnoDB

InnoDB是一個(gè)事務(wù)型的存儲引擎，有行級鎖定和外鍵約束。

Innodb引擎提供了對數(shù)據(jù)庫ACID事務(wù)的支持，并且實(shí)現(xiàn)了SQL標(biāo)準(zhǔn)的四種隔離級別，關(guān)于數(shù)據(jù)庫事務(wù)與其隔離級別的內(nèi)容請見數(shù)據(jù)庫事務(wù)與其隔離級別這類型的文章。該引擎還提供了行級鎖和外鍵約束，它的設(shè)計(jì)目標(biāo)是處理大容量數(shù)據(jù)庫系統(tǒng)，它本身其實(shí)就是基于MySQL后臺的完整數(shù)據(jù)庫系統(tǒng)，MySQL運(yùn)行時(shí)Innodb會(huì)在內(nèi)存中建立緩沖池，用于緩沖數(shù)據(jù)和索引。但是該引擎不支持FULLTEXT類型的索引，而且它沒有保存表的行數(shù)，當(dāng)SELECT COUNT(*) FROM TABLE時(shí)需要掃描全表。當(dāng)需要使用數(shù)據(jù)

庫事務(wù)時(shí)，該引擎當(dāng)然是首選。由于鎖的粒度更小，寫操作不會(huì)鎖定全表，所以在并發(fā)較高時(shí)，使用Innodb引擎會(huì)提升效率。但是使用行級鎖也不是絕對的，如果在執(zhí)行一個(gè)SQL語句時(shí)MySQL不能確定要掃描的范圍，InnoDB表同樣會(huì)鎖全表。

適用場景：

• 經(jīng)常更新的表，適合處理多重并發(fā)的更新請求。
• 支持事務(wù)。
• 可以從災(zāi)難中恢復(fù)（通過bin-log日志等）。
• 外鍵約束。只有他支持外鍵。
• 支持自動(dòng)增加列屬性auto_increment。

索引結(jié)構(gòu)：

• InnoDB也是B+Treee索引結(jié)構(gòu)。Innodb的索引文件本身就是數(shù)據(jù)文件，即B+Tree的數(shù)據(jù)域存儲的就是實(shí)際的數(shù)據(jù)，這種索引就是聚集索引。這個(gè)索引的key就是數(shù)據(jù)表的主鍵，因此InnoDB表數(shù)據(jù)文件本身就是主索引。
• InnoDB的輔助索引數(shù)據(jù)域存儲的也是相應(yīng)記錄主鍵的值而不是地址，所以當(dāng)以輔助索引查找時(shí)，會(huì)先根據(jù)輔助索引找到主鍵，再根據(jù)主鍵索引找到實(shí)際的數(shù)據(jù)。所以innodb不建議使用過長的主鍵，否則會(huì)使輔助索引變得過大。建議使用自增的字段作為主鍵，這樣B+Tree的每一個(gè)結(jié)點(diǎn)都會(huì)被順序的填滿，而不會(huì)頻繁的分裂調(diào)整，會(huì)有效的提升插入數(shù)據(jù)的效率。

2.3、Mylsam

MyIASM是MySQL默認(rèn)的引擎，但是它沒有提供對數(shù)據(jù)庫事務(wù)的支持，也不支持行級鎖和外鍵，因此當(dāng)INSERT或UPDATE數(shù)據(jù)時(shí)即寫操作需要鎖定整個(gè)表，效率便會(huì)低一些。MyIsam 存儲引擎獨(dú)立于操作系統(tǒng)，也就是可以在windows上使用，也可以比較簡單的將數(shù)據(jù)轉(zhuǎn)移到linux操作系統(tǒng)上去。

適用場景：

• 不支持事務(wù)的設(shè)計(jì)，但是并不代表著有事務(wù)操作的項(xiàng)目不能用MyIsam存儲引擎，可以在service層進(jìn)行根據(jù)自己的業(yè)務(wù)需求進(jìn)行相應(yīng)的控制。
• 不支持外鍵的表設(shè)計(jì)。
• 查詢速度很快，如果數(shù)據(jù)庫insert和update的操作比較多的話比較適用。
• 整天對表進(jìn)行加鎖的場景。
• MyISAM極度強(qiáng)調(diào)快速讀取操作。
• MyIASM中存儲了表的行數(shù)，于是SELECT COUNT(*) FROM TABLE時(shí)只需要直接讀取已經(jīng)保存好的值而不需要進(jìn)行全表掃描。如果表的讀操作遠(yuǎn)遠(yuǎn)多于寫操作且不需要數(shù)據(jù)庫事務(wù)的支持，那么MyIASM也是很好的選擇。

缺點(diǎn)：就是不能在表損壞后主動(dòng)恢復(fù)數(shù)據(jù)。

索引結(jié)構(gòu)：

MyISAM索引結(jié)構(gòu)：MyISAM索引用的B+ tree來儲存數(shù)據(jù)，MyISAM索引的指針指向的是鍵值的地址，地址存儲的是數(shù)據(jù)。B+Tree的數(shù)據(jù)域存儲的內(nèi)容為實(shí)際數(shù)據(jù)的地址，也就是說它的索引和實(shí)際的數(shù)據(jù)是分開的，只不過是用索引指向了實(shí)際的數(shù)據(jù)，這種索引就是所謂的非聚集索引。

2.4、InnoDB和Mylsam的區(qū)別：

1. 事務(wù)：MyISAM類型不支持事務(wù)處理等高級處理，而InnoDB類型支持，提供事務(wù)支持已經(jīng)外部鍵等高級數(shù)據(jù)庫功能。

2. 性能：MyISAM類型的表強(qiáng)調(diào)的是性能，其執(zhí)行數(shù)度比InnoDB類型更快。

3. 行數(shù)保存：InnoDB 中不保存表的具體行數(shù)，也就是說，執(zhí)行select count() fromtable時(shí)，InnoDB要掃描一遍整個(gè)表來計(jì)算有多少行，但是MyISAM只要簡單的讀出保存好的行數(shù)即可。注意的是，當(dāng)count()語句包含where條件時(shí)，兩種表的操作是一樣的。

4. 索引存儲：對于AUTO_INCREMENT類型的字段，InnoDB中必須包含只有該字段的索引，但是在MyISAM表中，可以和其他字段一起建立聯(lián)合索引。MyISAM支持全文索引（FULLTEXT）、壓縮索引，InnoDB不支持。

   MyISAM的索引和數(shù)據(jù)是分開的，并且索引是有壓縮的，內(nèi)存使用率就對應(yīng)提高了不少。能加載更多索引，而Innodb是索引和數(shù)據(jù)是緊密捆綁的，沒有使用壓縮從而會(huì)造成Innodb比MyISAM體積龐大不小。
   InnoDB存儲引擎被完全與MySQL服務(wù)器整合，InnoDB存儲引擎為在主內(nèi)存中緩存數(shù)據(jù)和索引而維持它自己的緩沖池。InnoDB存儲它的表＆索引在一個(gè)表空間中，表空間可以包含數(shù)個(gè)文件（或原始磁盤分區(qū)）。這與MyISAM表不同，比如在MyISAM表中每個(gè)表被存在分離的文件中。InnoDB 表可以是任何尺寸，即使在文件尺寸被限制為2GB的操作系統(tǒng)上。

5. 服務(wù)器數(shù)據(jù)備份：InnoDB必須導(dǎo)出SQL來備份，LOAD TABLE FROM MASTER操作對InnoDB是不起作用的，解決方法是首先把InnoDB表改成MyISAM表，導(dǎo)入數(shù)據(jù)后再改成InnoDB表，但是對于使用的額外的InnoDB特性(例如外鍵)的表不適用。

   MyISAM應(yīng)對錯(cuò)誤編碼導(dǎo)致的數(shù)據(jù)恢復(fù)速度快。MyISAM的數(shù)據(jù)是以文件的形式存儲，所以在跨平臺的數(shù)據(jù)轉(zhuǎn)移中會(huì)很方便。在備份和恢復(fù)時(shí)可單獨(dú)針對某個(gè)表進(jìn)行操作。
   InnoDB是拷貝數(shù)據(jù)文件、備份 binlog，或者用 mysqldump，在數(shù)據(jù)量達(dá)到幾十G的時(shí)候就相對痛苦了。

6. 鎖的支持：MyISAM只支持表鎖。InnoDB支持表鎖、行鎖。行鎖大幅度提高了多用戶并發(fā)操作的能力。但是InnoDB的行鎖，只是在WHERE的主鍵是有效的，非主鍵的WHERE都會(huì)鎖全表的。

3、MySQL的MVCC機(jī)制

MVCC是一種多版本并發(fā)控制機(jī)制，是MySQL的InnoDB存儲引擎實(shí)現(xiàn)隔離級別的一種具體方式，用于實(shí)現(xiàn)提交讀和可重復(fù)讀這兩種隔離級別。MVCC是通過保存數(shù)據(jù)在某個(gè)時(shí)間點(diǎn)的快照來實(shí)現(xiàn)該機(jī)制，其在每行記錄后面保存兩個(gè)隱藏的列，分別保存這個(gè)行的創(chuàng)建版本號和刪除版本號，然后Innodb的MVCC使用到的快照存儲在Undo日志中，該日志通過回滾指針把一個(gè)數(shù)據(jù)行所有快照連接起來。

4、事務(wù)

事務(wù)（Transaction）是由一系列對系統(tǒng)中數(shù)據(jù)進(jìn)行訪問與更新的操作所組成的一個(gè)程序執(zhí)行邏輯單元。事務(wù)是DBMS中最基礎(chǔ)的單位，事務(wù)不可分割。

事務(wù)具有4個(gè)基本特征，分別是：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Duration），簡稱ACID。

1. 原子性（Atomicity）

原子性是指事務(wù)包含的所有操作要么全部成功，要么全部失敗回滾，因此事務(wù)的操作如果成功就必須要完全應(yīng)用到數(shù)據(jù)庫，如果操作失敗則不能對數(shù)據(jù)庫有任何影響。

2. 一致性（Consistency）

一致性是指事務(wù)必須使數(shù)據(jù)庫從一個(gè)一致性狀態(tài)變換到另一個(gè)一致性狀態(tài)，也就是說一個(gè)事務(wù)執(zhí)行之前和執(zhí)行之后都必須處于一致性狀態(tài)。

拿轉(zhuǎn)賬來說，假設(shè)用戶A和用戶B兩者的錢加起來一共是5000，那么不管A和B之間如何轉(zhuǎn)賬，轉(zhuǎn)幾次賬，事務(wù)結(jié)束后兩個(gè)用戶的錢相加起來應(yīng)該還得是5000，這就是事務(wù)的一致性。

3. 隔離性（Isolation）

隔離性是當(dāng)多個(gè)用戶并發(fā)訪問數(shù)據(jù)庫時(shí)，比如操作同一張表時(shí)，數(shù)據(jù)庫為每一個(gè)用戶開啟的事務(wù)，不能被其他事務(wù)的操作所干擾，多個(gè)并發(fā)事務(wù)之間要相互隔離。

即要達(dá)到這么一種效果：對于任意兩個(gè)并發(fā)的事務(wù)T1和T2，在事務(wù)T1看來，T2要么在T1開始之前就已經(jīng)結(jié)束，要么在T1結(jié)束之后才開始，這樣每個(gè)事務(wù)都感覺不到有其他事務(wù)在并發(fā)地執(zhí)行。

多個(gè)事務(wù)并發(fā)訪問時(shí)，事務(wù)之間是隔離的，一個(gè)事務(wù)不應(yīng)該影響其它事務(wù)運(yùn)行效果。這指的是在并發(fā)環(huán)境中，當(dāng)不同的事務(wù)同時(shí)操縱相同的數(shù)據(jù)時(shí)，每個(gè)事務(wù)都有各自的完整數(shù)據(jù)空間。由并發(fā)事務(wù)所做的修改必須與任何其他并發(fā)事務(wù)所做的修改隔離。

不同的隔離級別：

• Read Uncommitted（讀取未提交[添加中文釋義]內(nèi)容）：最低的隔離級別，什么都不需要做，一個(gè)事務(wù)可以讀到另一個(gè)事務(wù)未提交的結(jié)果。所有的并發(fā)事務(wù)問題都會(huì)發(fā)生。
• Read Committed（讀取提交內(nèi)容）：只有在事務(wù)提交后，其更新結(jié)果才會(huì)被其他事務(wù)看見?？梢越鉀Q臟讀問題。
• Repeated Read（可重復(fù)讀）：在一個(gè)事務(wù)中，對于同一份數(shù)據(jù)的讀取結(jié)果總是相同的，無論是否有其他事務(wù)對這份數(shù)據(jù)進(jìn)行操作，以及這個(gè)事務(wù)是否提交。可以解決臟讀、不可重復(fù)讀。
• Serialization（可串行化）：事務(wù)串行化執(zhí)行，隔離級別最高，犧牲了系統(tǒng)的并發(fā)性。可以解決并發(fā)事務(wù)的所有問題。

4. 持久性（Durability）

持久性是指一個(gè)事務(wù)一旦被提交了，那么對數(shù)據(jù)庫中的數(shù)據(jù)的改變就是永久性的，即便是在數(shù)據(jù)庫系統(tǒng)遇到故障的情況下也不會(huì)丟失提交事務(wù)的操作。

例如我們在使用JDBC操作數(shù)據(jù)庫時(shí)，在提交事務(wù)方法后，提示用戶事務(wù)操作完成，當(dāng)我們程序執(zhí)行完成直到看到提示后，就可以認(rèn)定事務(wù)以及正確提交，即使這時(shí)候數(shù)據(jù)庫出現(xiàn)了問題，也必須要將我們的事務(wù)完全執(zhí)行完成，否則就會(huì)造成我們看到提示事務(wù)處理完畢，但是數(shù)據(jù)庫因?yàn)楣收隙鴽]有執(zhí)行事務(wù)的重大錯(cuò)誤。

5、數(shù)據(jù)庫的三大范式

1. 第一范式：當(dāng)關(guān)系模式R的所有屬性都不能再分解為更基本的數(shù)據(jù)單位時(shí)，稱R是滿足第一范式，即屬性不可分。
2. 第二范式：如果關(guān)系模式R滿足第一范式，并且R得所有非主屬性都完全依賴于R的每一個(gè)候選關(guān)鍵屬性，稱R滿足第二范式。
3. 第三范式：設(shè)R是一個(gè)滿足第一范式條件的關(guān)系模式，X是R的任意屬性集，如果X非傳遞依賴于R的任意一個(gè)候選關(guān)鍵字，稱R滿足第三范式，即非主屬性不傳遞依賴于鍵碼。

6、數(shù)據(jù)庫的四種隔離級別

數(shù)據(jù)庫事務(wù)的隔離級別有4個(gè)，由低到高依次為Read uncommitted、Read committed、Repeatable read、Serializable，這四個(gè)級別可以逐個(gè)解決臟讀、不可重復(fù)讀、幻讀這幾類問題。

• ISOLATION_READ_UNCOMMITTED：這是事務(wù)最低的隔離級別，它充許令外一個(gè)事務(wù)可以看到這 個(gè)事務(wù)未提交的數(shù)據(jù)。這種隔離級別會(huì)產(chǎn)生臟讀，不可重復(fù)讀和幻像讀。
• ISOLATION_READ_COMMITTED：保證一個(gè)事務(wù)修改的數(shù)據(jù)提交后才能被另外一個(gè)事務(wù)讀取。另外 一個(gè)事務(wù)不能讀取該事務(wù)未提交的數(shù)據(jù)
• ISOLATION_REPEATABLE_READ：這種事務(wù)隔離級別可以防止臟讀，不可重復(fù)讀。但是可能出現(xiàn)幻 像讀。它除了保證一個(gè)事務(wù)不能讀取另一個(gè)事務(wù)未提交的數(shù)據(jù)外，還保證了避免下面的情況產(chǎn)生(不可重 復(fù)讀)。
• ISOLATION_SERIALIZABLE：這是花費(fèi)最高代價(jià)但是最可靠的事務(wù)隔離級別。事務(wù)被處理為順序執(zhí) 行。除了防止臟讀，不可重復(fù)讀外，還避免了幻像讀。

第1級別：Read Uncommitted(讀取未提交內(nèi)容)

(1)所有事務(wù)都可以看到其他未提交事務(wù)的執(zhí)行結(jié)果。

(2)本隔離級別很少用于實(shí)際應(yīng)用，因?yàn)樗男阅芤膊槐绕渌墑e好多少。

(3)該級別引發(fā)的問題是——臟讀(Dirty Read)：讀取到了未提交的數(shù)據(jù)。

第2級別：Read Committed(讀取提交內(nèi)容)

(1)這是大多數(shù)數(shù)據(jù)庫系統(tǒng)的默認(rèn)隔離級別（但不是MySQL默認(rèn)的）。

(2)它滿足了隔離的簡單定義：一個(gè)事務(wù)只能看見已經(jīng)提交事務(wù)所做的改變。

(3)這種隔離級別出現(xiàn)的問題是——不可重復(fù)讀(Nonrepeatable Read)：不可重復(fù)讀意味著我們在同一個(gè)事務(wù)中執(zhí)行完全相同的select語句時(shí)可能看到不一樣的結(jié)果。

導(dǎo)致這種情況的原因可能有：

• 有一個(gè)交叉的事務(wù)有新的commit，導(dǎo)致了數(shù)據(jù)的改變;
• 一個(gè)數(shù)據(jù)庫被多個(gè)實(shí)例操作時(shí),同一事務(wù)的其他實(shí)例在該實(shí)例處理其間可能會(huì)有新的commit。

第3級別：Repeatable Read(可重讀)

(1)這是MySQL的默認(rèn)事務(wù)隔離級別。

(2)它確保同一事務(wù)的多個(gè)實(shí)例在并發(fā)讀取數(shù)據(jù)時(shí)，會(huì)看到同樣的數(shù)據(jù)行。

(3)此級別可能出現(xiàn)的問題——幻讀(Phantom Read)：當(dāng)用戶讀取某一范圍的數(shù)據(jù)行時(shí)，另一個(gè)事務(wù)又在該范圍內(nèi)插入了新行，當(dāng)用戶再讀取該范圍的數(shù)據(jù)行時(shí)，會(huì)發(fā)現(xiàn)有新的“幻影” 行。

(4)InnoDB和Falcon存儲引擎通過多版本并發(fā)控制(MVCC，Multiversion Concurrency Control)機(jī)制解決了該問題。

第4級別：Serializable(可串行化)

(1)這是最高的隔離級別。

(2)它通過強(qiáng)制事務(wù)排序，使之不可能相互沖突，從而解決幻讀問題。簡言之,它是在每個(gè)讀的數(shù)據(jù)行上加上共享鎖。

(3)在這個(gè)級別，可能導(dǎo)致大量的超時(shí)現(xiàn)象和鎖競爭。