「知識集錦」mysql基礎(chǔ)知識&面試真題丨【綻放吧！數(shù)據(jù)庫】

謝謝那些曾經(jīng)擊倒我的人，躺著可真舒服。

目錄

一、知識體系

1、關(guān)系型數(shù)據(jù)庫術(shù)語

2、事務(wù)的基本要素（ACID）

3、事務(wù)的并發(fā)問題

二、面試真題

1、說一下 Mysql 常用的引擎？

2、Myisam和InnoDB的區(qū)別？

3、B樹和B+樹的概念和區(qū)別？

4、為什么選擇B+樹作為索引結(jié)構(gòu)？

5、B+樹的葉子節(jié)點都可以存哪些東西？

6、什么樣的信息能成為索引？

7、批量往Mysql導入1000萬數(shù)據(jù)有什么方法？

8、binlog和redolog有什么區(qū)別？

【系列課程介紹】

『面試知識集錦』系列課程包括以下20+個章節(jié)，超過100+篇文章，每篇文章的前半部分為「知識體系」幫助你打牢基礎(chǔ)，后半部分為「面試真題」幫助你拿下面試。

如果覺得還不錯，求、求、關(guān)注專欄。

一、知識體系

1、關(guān)系型數(shù)據(jù)庫術(shù)語

MySQL 是一個關(guān)系型數(shù)據(jù)庫管理系統(tǒng)，由瑞典 MySQL AB 公司開發(fā)，目前屬于 Oracle 公司。關(guān)聯(lián)數(shù)據(jù)庫將數(shù)據(jù)保存在不同的表中，而不是將所有數(shù)據(jù)放在一個大倉庫內(nèi)，這樣就增加了速度并提高了靈活性。

開始學習MySQL 數(shù)據(jù)庫前，讓我們先了解下RDBMS的一些術(shù)語：

數(shù)據(jù)庫:?數(shù)據(jù)庫是一些關(guān)聯(lián)表的集合。

數(shù)據(jù)表:?表是數(shù)據(jù)的矩陣。在一個數(shù)據(jù)庫中的表看起來像一個簡單的電子表格。

列:?一列(數(shù)據(jù)元素) 包含了相同類型的數(shù)據(jù), 例如郵政編碼的數(shù)據(jù)。

行：一行（=元組，或記錄）是一組相關(guān)的數(shù)據(jù)，例如一條用戶訂閱的數(shù)據(jù)。

冗余：存儲兩倍數(shù)據(jù)，冗余降低了性能，但提高了數(shù)據(jù)的安全性。

主鍵：主鍵是唯一的。一個數(shù)據(jù)表中只能包含一個主鍵。你可以使用主鍵來查詢數(shù)據(jù)。

外鍵：外鍵用于關(guān)聯(lián)兩個表。

復合鍵：復合鍵（組合鍵）將多個列作為一個索引鍵，一般用于復合索引。

索引：使用索引可快速訪問數(shù)據(jù)庫表中的特定信息。索引是對數(shù)據(jù)庫表中一列或多列的值進行排序的一種結(jié)構(gòu)。類似于書籍的目錄。

參照完整性:?參照的完整性要求關(guān)系中不允許引用不存在的實體。與實體完整性是關(guān)系模型必須滿足的完整性約束條件，目的是保證數(shù)據(jù)的一致性。

2、事務(wù)的基本要素（ACID）

1、原子性（Atomicity）：事務(wù)開始后所有操作，要么全部做完，要么全部不做，不可能停滯在中間環(huán)節(jié)。事務(wù)執(zhí)行過程中出錯，會回滾到事務(wù)開始前的狀態(tài)，所有的操作就像沒有發(fā)生一樣。也就是說事務(wù)是一個不可分割的整體，就像化學中學過的原子，是物質(zhì)構(gòu)成的基本單位

2、一致性（Consistency）：事務(wù)開始前和結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞 。比如A向B轉(zhuǎn)賬，不可能A扣了錢，B卻沒收到。

3、隔離性（Isolation）：同一時間，只允許一個事務(wù)請求同一數(shù)據(jù)，不同的事務(wù)之間彼此沒有任何干擾。比如A正在從一張銀行卡中取錢，在A取錢的過程結(jié)束前，B不能向這張卡轉(zhuǎn)賬。

4、持久性（Durability）：事務(wù)完成后，事務(wù)對數(shù)據(jù)庫的所有更新將被保存到數(shù)據(jù)庫，不能回滾。

3、事務(wù)的并發(fā)問題

1、臟讀：事務(wù)A讀取了事務(wù)B更新的數(shù)據(jù)，然后B回滾操作，那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)

2、不可重復讀：事務(wù) A 多次讀取同一數(shù)據(jù)，事務(wù) B 在事務(wù)A多次讀取的過程中，對數(shù)據(jù)作了更新并提交，導致事務(wù)A多次讀取同一數(shù)據(jù)時，結(jié)果 不一致

3、幻讀：系統(tǒng)管理員A將數(shù)據(jù)庫中所有學生的成績從具體分數(shù)改為ABCDE等級，但是系統(tǒng)管理員B就在這個時候插入了一條具體分數(shù)的記錄，當系統(tǒng)管理員A改結(jié)束后發(fā)現(xiàn)還有一條記錄沒有改過來，就好像發(fā)生了幻覺一樣，這就叫幻讀。

小結(jié)：不可重復讀的和幻讀很容易混淆，不可重復讀側(cè)重于修改，幻讀側(cè)重于新增或刪除。解決不可重復讀的問題只需鎖住滿足條件的行，解決幻讀需要鎖表

二、面試真題

1、說一下 mysql 常用的引擎？

InnoDB 引擎：MySQL 的5.5之后的默認引擎，InnoDB 引擎提供了對數(shù)據(jù)庫事務(wù)的支持，并且還提供了行級鎖和外鍵的約束，它的設(shè)計的目標就是處理大數(shù)據(jù)容量的數(shù)據(jù)庫系統(tǒng)。MySQL 運行的時候，InnoDB 會在內(nèi)存中建立緩沖池，用于緩沖數(shù)據(jù)和索引。由于鎖的粒度小，寫操作是不會鎖定全表的,所以在并發(fā)度較高的場景下使用會提升效率的。

MyISAM 引擎：不提供事務(wù)的支持，也不支持行級鎖和外鍵。因此當執(zhí)行插入和更新語句時，即執(zhí)行寫操作的時候需要鎖定這個表，所以會導致效率會降低。不過和 InnoDB 不同的是，MyIASM 引擎是保存了表的行數(shù)，于是當進行 select count(*) from table 語句時，可以直接的讀取已經(jīng)保存的值而不需要進行掃描全表。所以，如果表的讀操作遠遠多于寫操作時，并且不需要事務(wù)的支持的，可以將 MyIASM 作為數(shù)據(jù)庫引擎的首選。

2、Myisam和InnoDB的區(qū)別？

對比項

MyISAM

InnoDB

外鍵

不支持

支持

事務(wù)

不支持

支持

行表鎖

表鎖，即使操作一條記錄也會鎖住整個表，不適合高并發(fā)的操作

行鎖,操作時只鎖某一行，不對其它行有影響，

適合高并發(fā)的操作

緩存

只緩存索引，不緩存真實數(shù)據(jù)

不僅緩存索引還要緩存真實數(shù)據(jù)，對內(nèi)存要求較高，而且內(nèi)存大小對性能有決定性的影響

是否支持行級鎖?: MyISAM 只有表級鎖(table-level locking)，而InnoDB 支持行級鎖(row-level locking)和表級鎖,默認為行級鎖，適合高并發(fā)操作。

是否支持外鍵： MyISAM不支持，而InnoDB支持

是否支持事務(wù)：MyISAM不支持，而InnoDB支持

緩存：MyISAM只緩存索引，InnoDB緩存索引和真實數(shù)據(jù)，所以對內(nèi)存要求高

崩潰恢復：MyISAM 崩潰后發(fā)生損壞的概率比 InnoDB 高很多，而且恢復的速度也更慢。

3、B樹和B+樹的概念和區(qū)別？

1）B-樹的關(guān)鍵字和記錄是放在一起的，葉子節(jié)點可以看作外部節(jié)點，不包含任何信息；B+樹的非葉子節(jié)點中只有關(guān)鍵字和指向下一個節(jié)點的索引，記錄只放在葉子節(jié)點中。

2）在B-樹中，越靠近根節(jié)點的記錄查找時間越快，只要找到關(guān)鍵字即可確定記錄的存在；而B+樹中每個記錄的查找時間基本是一樣的，都需要從根節(jié)點走到葉子節(jié)點，而且在葉子節(jié)點中還要再比較關(guān)鍵字。從這個角度看B-樹的性能好像要比B+樹好，而在實際應(yīng)用中卻是B+樹的性能要好些。

4、為什么選擇B+樹作為索引結(jié)構(gòu)？

因為B+樹的非葉子節(jié)點不存放實際的數(shù)據(jù)，這樣每個節(jié)點可容納的元素個數(shù)比B-樹多，樹高比B-樹小，這樣帶來的好處是減少磁盤訪問次數(shù)。盡管B+樹找到一個記錄所需的比較次數(shù)要比B-樹多，但是一次磁盤訪問的時間相當于成百上千次內(nèi)存比較的時間，因此實際中B+樹的性能可能還會好些。

B+樹的葉子節(jié)點使用指針連接在一起，方便順序遍歷（例如查看一個目錄下的所有文件，一個表中的所有記錄等）。

B+樹的查詢效率更加穩(wěn)定，每次查詢的效率一樣。

Hash索引底層是哈希表，哈希表是一種以key-value存儲數(shù)據(jù)的結(jié)構(gòu)，所以多個數(shù)據(jù)在存儲關(guān)系上是完全沒有任何順序關(guān)系的，所以，對于區(qū)間查詢是無法直接通過索引查詢的，就需要全表掃描。所以，哈希索引只適用于等值查詢的場景。而B+ 樹是一種多路平衡查詢樹，所以他的節(jié)點是天然有序的（左子節(jié)點小于父節(jié)點、父節(jié)點小于右子節(jié)點），所以對于范圍查詢的時候不需要做全表掃描

二叉查找樹：解決了排序的基本問題，但是由于無法保證平衡，可能退化為鏈表。

平衡二叉樹：通過旋轉(zhuǎn)解決了平衡的問題，但是旋轉(zhuǎn)操作效率太低。

紅黑樹：通過舍棄嚴格的平衡和引入紅黑節(jié)點，解決了 AVL旋轉(zhuǎn)效率過低的問題，但是在磁盤等場景下，樹仍然太高，IO次數(shù)太多。

5、B+樹的葉子節(jié)點都可以存哪些東西？

可能存儲的是整行數(shù)據(jù)，也有可能是主鍵的值

6、什么樣的信息能成為索引？

主鍵，唯一鍵，普通鍵都可，只要能讓數(shù)據(jù)有一定區(qū)分性的字段。

7、批量往mysql導入1000萬數(shù)據(jù)有什么方法？

減少IO次數(shù)

SQL寫法優(yōu)化，一條SQL語句插入多條數(shù)據(jù)

合理設(shè)置批量大小

盡量順序插入， 減少索引的維護壓力

8、binlog和redolog有什么區(qū)別？

redolog是在InnoDB存儲引擎層產(chǎn)生，而binlog是MySQL數(shù)據(jù)庫的上層服務(wù)層產(chǎn)生的。

兩種日志記錄的內(nèi)容形式不同。MySQL的binlog是邏輯日志，其記錄是對應(yīng)的SQL語句。而innodb存儲引擎層面的重做日志是物理日志。

兩種日志與記錄寫入磁盤的時間點不同，binlog日志只在事務(wù)提交完成后進行一次寫入。而innodb存儲引擎的重做日志在事務(wù)進行中不斷地被寫入，并日志不是隨事務(wù)提交的順序進行寫入的。

binlog不是循環(huán)使用，在寫滿或者重啟之后，會生成新的binlog文件，redolog是循環(huán)使用。

binlog可以作為恢復數(shù)據(jù)使用，主從復制搭建，redolog作為異常宕機或者介質(zhì)故障后的數(shù)據(jù)恢復使用。

好了，本節(jié)分享就到這里......、、關(guān)注專欄之后，回去等通知吧！

【綻放吧！數(shù)據(jù)庫】有獎?wù)魑幕馃徇M行中：https://bbs.huaweicloud.com/blogs/285617

MySQL 數(shù)據(jù)庫

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔相應(yīng)法律責任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實的內(nèi)容，請聯(lián)系我們jiasou666@gmail.com 處理，核實后本網(wǎng)站將在24小時內(nèi)刪除侵權(quán)內(nèi)容。