數(shù)據(jù)庫面試知識點(diǎn)匯總

1.簡述關(guān)系型與非關(guān)系型數(shù)據(jù)庫的區(qū)別？

關(guān)系型數(shù)據(jù)庫是依據(jù)關(guān)系模型來創(chuàng)建的數(shù)據(jù)庫，所謂關(guān)系模型就是“一對一”、“一對多”、“對多對”等。常見的關(guān)系型數(shù)據(jù)庫有Oracle、MySQL、SQL Server等。

非關(guān)系型數(shù)據(jù)庫主要基于“非關(guān)系型模型”，其中非關(guān)系型模型有：列模型、鍵值對模型、文檔類模型。比如redis屬于鍵值對模型。

關(guān)系型數(shù)據(jù)庫的優(yōu)點(diǎn)：

易于維護(hù)：都是使用表結(jié)構(gòu)，格式一致。

使用方便：SQL語言通用，可用于復(fù)雜查詢。

復(fù)雜操作：支持SQL，可用于一個表以及多個表之間非常復(fù)雜的查詢。

關(guān)系型數(shù)據(jù)庫的缺點(diǎn)：

讀寫性能比較差，尤其是海量數(shù)據(jù)的高效率讀寫。

固定的表結(jié)構(gòu)，靈活度稍欠。

高并發(fā)讀寫需求，傳統(tǒng)關(guān)系型數(shù)據(jù)庫來說，硬盤I/O是一個很大的瓶頸。

非關(guān)系型數(shù)據(jù)庫的優(yōu)點(diǎn)：

格式靈活：存儲數(shù)據(jù)的格式可以是key,value形式、文檔形式、圖片形式等，使用靈活，應(yīng)用場景廣泛，而關(guān)系型數(shù)據(jù)庫則只支持基礎(chǔ)類型。

速度快：nosql可使用硬盤或者隨機(jī)存儲器作為載體，關(guān)系型數(shù)據(jù)庫只能使用硬盤。

高拓展性

成本低：nosql數(shù)據(jù)庫部署簡單，基本都是開源軟件。

非關(guān)系型數(shù)據(jù)庫的缺點(diǎn)：

不提供sql支持，學(xué)習(xí)和使用成本較高。

無事務(wù)處理。

數(shù)據(jù)結(jié)構(gòu)相對復(fù)雜，復(fù)雜查詢方面稍欠。

2.簡述為什么需要使用索引？

通過創(chuàng)建唯一性索引，可以保證數(shù)據(jù)庫表中每一行數(shù)據(jù)的唯一性。

可以加快數(shù)據(jù)的檢索速度，是創(chuàng)建索引的主要原因。

減少磁盤IO，可以直接定位。

通過使用索引，可以在查詢過程中，使用優(yōu)化隱藏器，提高系統(tǒng)的性能

加速表與表的連接，特別是在實(shí)現(xiàn)數(shù)據(jù)的參考完整性方面特別有意義。

缺點(diǎn)：

創(chuàng)建索引和維護(hù)索引需要耗費(fèi)時間，時間隨著數(shù)據(jù)量的增加而增加。

索引需要占用物理空間，特別是聚簇索引，需要較大的空間。

當(dāng)對表中的數(shù)據(jù)進(jìn)行增加、刪除和修改的時候，索引也要動態(tài)的維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。

3.簡述數(shù)據(jù)庫索引采用B+樹不采用B樹的原因？

B+樹更便于遍歷：由于B+樹的數(shù)據(jù)都存儲在葉子結(jié)點(diǎn)中，分支結(jié)點(diǎn)均為索引，方便掃庫，只需要掃一遍葉子結(jié)點(diǎn)即可，但是B樹因?yàn)槠浞种ЫY(jié)點(diǎn)同樣存儲著數(shù)據(jù)，我們要找到具體的數(shù)據(jù)，需要進(jìn)行一次中序遍歷按序來掃，所以B+樹更加適合在區(qū)間查詢的情況，所以通常B+樹用于數(shù)據(jù)庫索引。

B+樹的磁盤讀寫代價更低：B+樹在內(nèi)部節(jié)點(diǎn)上不包含數(shù)據(jù)信息，因此在內(nèi)存頁中能夠存放更多的key。 數(shù)據(jù)存放的更加緊密，具有更好的空間局部性。因此訪問葉子節(jié)點(diǎn)上關(guān)聯(lián)的數(shù)據(jù)也具有更好的緩存命中率。

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)致每一個數(shù)據(jù)的查詢效率相當(dāng)。

B+樹更適合基于范圍的查詢 ：B樹在提高了IO性能的同時并沒有解決元素遍歷的效率低下的問題，正是為了解決這個問題，B+樹應(yīng)用而生。B+樹只需要去遍歷葉子節(jié)點(diǎn)就可以實(shí)現(xiàn)整棵樹的遍歷。而且在數(shù)據(jù)庫中基于范圍的查詢是非常頻繁的，而B樹不支持這樣的操作或者說效率太低。

4.簡述MySQL索引有哪些類型？

普通索引：最基本的索引，沒有任何限制。

唯一索引：索引列的值必須唯一，但可以有空值。可以創(chuàng)建組合索引，則列值的組合必須唯一。

主鍵索引：是特殊的唯一索引，不可以有空值，且表中只存在一個該值。

組合索引：多列值組成一個索引，用于組合搜索，效率高于索引合并。

全文索引：對文本的內(nèi)容進(jìn)行分詞，進(jìn)行搜索。

5.簡述什么是聚簇索引及其優(yōu)缺點(diǎn)？

聚簇索引并不是單獨(dú)的索引類型，而是一種數(shù)據(jù)存儲方式。

B+樹索引分為聚簇索引和非聚簇索引，主鍵索引就是聚簇索引的一種，非聚簇索引有復(fù)合索引、前綴索引、唯一索引。

在innodb存儲引擎中，表數(shù)據(jù)本身就是按B+樹組織的一個索引結(jié)構(gòu)，聚簇索引就是按照每張表的主鍵構(gòu)造一顆B+樹，同時葉子節(jié)點(diǎn)中存放的就是整張表的行記錄數(shù)據(jù)，也將聚簇索引的葉子節(jié)點(diǎn)成為數(shù)據(jù)頁。

Innodb通過主鍵聚集數(shù)據(jù)，如果沒有定義主鍵，innodb會選擇非空的唯一索引代替。如果沒有這樣的索引，innodb會隱式的定義一個主鍵來作為聚簇索引。

非聚簇索引又稱為輔助索引，InnoDB訪問數(shù)據(jù)需要兩次查找，輔助索引葉子節(jié)點(diǎn)存儲的不再是行的物理位置，而是主鍵值。通過輔助索引首先找到的是主鍵值，再通過主鍵值找到數(shù)據(jù)行的數(shù)據(jù)頁，再通過數(shù)據(jù)頁中的Page Directory找到數(shù)據(jù)行。

Innodb輔助索引的葉子節(jié)點(diǎn)并不包含行記錄的全部數(shù)據(jù)，葉子節(jié)點(diǎn)除了包含鍵值外，還包含了相應(yīng)行數(shù)據(jù)的聚簇索引鍵。一張表可有多個二級索引。

優(yōu)點(diǎn)：

數(shù)據(jù)訪問更快，因?yàn)榫鄞厮饕龑⑺饕蛿?shù)據(jù)保存在同一個B+樹中，因此從聚簇索引中獲取數(shù)據(jù)比非聚簇索引更快。

聚簇索引對于主鍵的排序查找和范圍查找速度非常快。

缺點(diǎn)：

插入速度嚴(yán)重依賴于插入順序，按照主鍵的順序插入是最快的方式，否則將會出現(xiàn)頁分裂，嚴(yán)重影響性能。因此，對于InnoDB表，我們一般都會定義一個自增的ID列為主鍵。

更新主鍵的代價很高，因?yàn)閷?dǎo)致被更新的行移動。因此，對于InnoDB表，我們一般定義主鍵為不可更新。

二級索引訪問要兩次索引查找，第一次找到主鍵值，第二次根據(jù)主鍵值找到行數(shù)據(jù)。

6.簡述InnoDB與MyISAM實(shí)現(xiàn)索引方式的區(qū)別？

首先兩者都是用的是B+樹索引，但二者的實(shí)現(xiàn)方式不同。

對于主鍵索引，InnoDB中葉子節(jié)點(diǎn)保存了完整的數(shù)據(jù)記錄，而MyISAM中索引文件與數(shù)據(jù)文件是分離的，葉子節(jié)點(diǎn)上的索引文件僅保存了數(shù)據(jù)記錄的地址.

對于輔助索引，InnoDB中輔助索引會對主鍵進(jìn)行存儲，查找時，先通過輔助索引的B+樹在葉子節(jié)點(diǎn)獲取對應(yīng)的主鍵，然后使用主鍵在主索引B+樹上檢索操作，最終得到行數(shù)據(jù)；MyISAM中要求主索引是唯一的，而輔助索引可以是重復(fù)的，主索引與輔助索引沒有任何區(qū)別，因此，MyISAM中索引檢索的算法為首先按照B+Tree搜索算法搜索索引，如果指定的Key存在，則取出其data域的值，然后以data域的值為地址，讀取相應(yīng)數(shù)據(jù)記錄。

7.簡述什么是聚簇索引與非聚簇索引？

聚簇索引：將數(shù)據(jù)存儲與索引放到了一塊，找到索引也就找到了數(shù)據(jù)。

非聚簇索引：將數(shù)據(jù)存儲于索引分開結(jié)構(gòu)，索引結(jié)構(gòu)的葉子節(jié)點(diǎn)指向了數(shù)據(jù)的對應(yīng)行，MyISAM通過key_buffer把索引先緩存到內(nèi)存中，當(dāng)需要訪問數(shù)據(jù)時（通過索引訪問數(shù)據(jù)），在內(nèi)存中直接搜索索引，然后通過索引找到磁盤相應(yīng)數(shù)據(jù)，這也就是為什么索引不在key buffer命中時，速度慢的原因。

8.主鍵索引是聚集索引還是非聚集索引？

聚集索引決定了數(shù)據(jù)庫的物理存儲結(jié)構(gòu)，而主鍵只是確定表格邏輯組織方式。這兩者不可混淆！

在InnoDB下主鍵索引是聚集索引，在MyISAM下主鍵索引是非聚集索引。

9.簡述InnoDB為什么使用自增id作為主鍵？

MySQL底層使用是使用數(shù)據(jù)頁為單位來存儲數(shù)據(jù)的，一個數(shù)據(jù)頁大小默認(rèn)為16K，當(dāng)數(shù)據(jù)頁滿了，就會申請新的數(shù)據(jù)頁進(jìn)行存儲數(shù)據(jù)。

如果主鍵為自增 id 的話，mysql 在寫滿一個數(shù)據(jù)頁的時候，直接申請另一個新數(shù)據(jù)頁接著寫就可以了。

如果主鍵是非自增 id，為了確保索引有序，mysql 就需要將每次插入的數(shù)據(jù)都放到合適的位置上。當(dāng)往一個快滿或已滿的數(shù)據(jù)頁中插入數(shù)據(jù)時，新插入的數(shù)據(jù)會將數(shù)據(jù)頁寫滿，mysql 需要申請新的數(shù)據(jù)頁，并且把上個數(shù)據(jù)頁中的部分?jǐn)?shù)據(jù)挪到新的數(shù)據(jù)頁上。這就造成了頁分裂，這個大量移動數(shù)據(jù)的過程是會嚴(yán)重影響插入效率。

10.簡述為什么主鍵越小越好？

主鍵占用空間越大，每個頁存儲的主鍵個數(shù)越少，路樹就越少，B+樹的深度會邊長，導(dǎo)致IO次數(shù)會變多。

輔助索引的葉子節(jié)點(diǎn)上保存的是主鍵 id 的值，如果主鍵 id 占空間較大的話，那將會成倍增加 mysql 空間占用大小。

11.簡述數(shù)據(jù)庫執(zhí)行查詢請求的過程？

客戶端請求：建立TCP連接。

使用連接器進(jìn)行連接管理：此時服務(wù)端會對客戶端發(fā)來數(shù)據(jù)攜帶的主機(jī)信息、用戶名、密碼等信息進(jìn)行驗(yàn)證，如果認(rèn)證失敗就會拒絕連接。（連接器）
注： 當(dāng)客戶端連接服務(wù)端進(jìn)程后，服務(wù)端進(jìn)程會為其創(chuàng)建進(jìn)程專門用于交互，當(dāng)斷開連接后，服務(wù)端不會立即進(jìn)行銷毀，而是會進(jìn)行緩存，用于下次新的連接，這樣可以不用頻繁的創(chuàng)建和銷毀線程，節(jié)省開銷。

緩存查詢：服務(wù)端會對之前的請求結(jié)果進(jìn)行緩存，若存在緩存直接返回，否則繼續(xù)執(zhí)行下一步。維護(hù)緩存的代價較大，因此在8.0版本后已刪除緩存。

語法解析：由于目前為止還未對文本解析，此時會對文本進(jìn)行詞法分析、語法分析、語義分析等過程，真正開始解析。（分析器）

查詢優(yōu)化：主要對執(zhí)行的sql優(yōu)化選擇最優(yōu)的執(zhí)行方案。（優(yōu)化器）

存儲引擎：執(zhí)行時會先看用戶是否有執(zhí)行權(quán)限，有才去使用這個引擎提供的接口。然后去引擎層獲取數(shù)據(jù)返回，若開啟查詢緩存則會緩存查詢結(jié)果。（執(zhí)行器）

12.簡述臟讀、幻讀、不可重復(fù)讀的定義？

臟讀：指當(dāng)一個事務(wù)正在訪問數(shù)據(jù)，并且對數(shù)據(jù)進(jìn)行了修改，而這種數(shù)據(jù)還沒有提交到數(shù)據(jù)庫中，這時，另外一個事務(wù)也訪問這個數(shù)據(jù)，然后使用了這個數(shù)據(jù)。因?yàn)檫@個數(shù)據(jù)還沒有提交那么另外一個事務(wù)讀取到的這個數(shù)據(jù)我們稱之為臟數(shù)據(jù)。

不可重復(fù)讀：指在一個事務(wù)內(nèi)，多次讀同一數(shù)據(jù)。在這個事務(wù)還沒有執(zhí)行結(jié)束，另外一個事務(wù)也訪問該同一數(shù)據(jù)，那么在第一個事務(wù)中的兩次讀取數(shù)據(jù)之間，由于第二個事務(wù)的修改第一個事務(wù)兩次讀到的數(shù)據(jù)可能是不一樣的，這樣就發(fā)生了在一個事務(wù)內(nèi)兩次連續(xù)讀到的數(shù)據(jù)是不一樣的，這種情況被稱為是不可重復(fù)讀。

幻讀：一個事務(wù)先后讀取一個范圍的記錄，但兩次讀取的紀(jì)錄數(shù)不同，我們稱之為幻象讀。（兩次執(zhí)行同一條 select 語句會出現(xiàn)不同的結(jié)果，第二次讀會增加一數(shù)據(jù)行，并沒有說這兩次執(zhí)行是在同一個事務(wù)中）

13.簡述數(shù)據(jù)庫的隔離級別？

讀未提交：指一個事務(wù)讀取另一個事務(wù)未提交的修改。，會發(fā)生臟讀、不可重復(fù)讀、幻讀。

讀提交：指只能讀到已經(jīng)提交的內(nèi)容。會發(fā)生不可重復(fù)讀和幻讀。是SQL Server和Oracle的默認(rèn)隔離級別。

可重復(fù)讀：指當(dāng)數(shù)據(jù)被讀取時，不可進(jìn)行update操作，保證多次讀取的記錄是相同的，解決了不可重復(fù)讀的問題。但幻讀是insert導(dǎo)致，不會避免。可重復(fù)讀是MySQL的默認(rèn)隔離級別。

可串行化讀：這是數(shù)據(jù)庫最高的隔離級別，這種級別下，事務(wù)“串行化順序執(zhí)行”，也就是一個一個排隊(duì)執(zhí)行。這種級別下，“臟讀”、“不可重復(fù)讀”、“幻讀”都可以被避免，但是執(zhí)行效率奇差，性能開銷也最大，所以基本沒人會用。

14.簡述MySQL可以從哪些方面做到性能優(yōu)化?

為搜索字段創(chuàng)建索引。

避免使用 Select *，列出需要查詢的字段。

垂直分割分表，水平分割是分割記錄，以一條記錄/行為單位。垂直分割則是以列為單位，將列分割出去。

選擇正確的搜索引擎。

實(shí)現(xiàn)數(shù)據(jù)庫的主從同步，實(shí)現(xiàn)讀寫分離。

添加合適的緩存機(jī)制，維護(hù)代價高。

對冷熱數(shù)據(jù)進(jìn)行均分，減少單個庫的壓力，使整體性能達(dá)到更優(yōu)。

15.簡述MySQL為什么需要事務(wù)回滾機(jī)制？

在MySQL中事務(wù)回滾通過日志完成，所有事務(wù)進(jìn)行的修改都會先記錄到回滾日志中，然后再對數(shù)據(jù)庫中的對應(yīng)行進(jìn)行寫入。當(dāng)事務(wù)被提交后就無法回滾了。

回滾日志的作用：

能夠在發(fā)生錯誤或用戶執(zhí)行rollback時提供回滾的相關(guān)信息。

在整個系統(tǒng)發(fā)生崩潰、數(shù)據(jù)庫進(jìn)程直接被殺死后，當(dāng)用戶再次啟動數(shù)據(jù)庫進(jìn)程時，還能夠立刻通過查詢回滾日志將之前未完成的事務(wù)進(jìn)行回滾，這也就需要回滾日志必須先于數(shù)據(jù)持久化到磁盤上，是我們需要先寫日志后寫數(shù)據(jù)庫的主要原因。

16.簡述MySQL引擎InnoDB和MyISAM的區(qū)別？

InnoDB：

是MySQL默認(rèn)的事務(wù)型存儲引擎，只有當(dāng)需要它不支持的特性時，才會考慮使用其它的存儲引擎。

實(shí)現(xiàn)了四個標(biāo)準(zhǔn)的隔離級別，其中默認(rèn)為可重復(fù)讀，在可重復(fù)讀的隔離級別下，通過MVCC（多版本并發(fā)控制協(xié)議）+ 間隙鎖（Next-key Locking）防止幻讀。

主索引為聚簇索引，在索引中保存數(shù)據(jù)，從而避免直接讀取磁盤，因此對查詢性能有很大的提升。

支持真正的在線熱備份。其它存儲引擎不支持在線熱備份。

支持行級鎖，通過給索引項(xiàng)加鎖來實(shí)現(xiàn)，即只有通過索引條件檢索數(shù)據(jù)，才會使用行級鎖，否則使用表鎖。

InnoDB不會對表中行的總量進(jìn)行預(yù)先統(tǒng)計(jì)，每次count需要遍歷計(jì)算。

MyISAM：

設(shè)計(jì)簡單，數(shù)據(jù)以緊密格式存儲。對于只讀數(shù)據(jù)，或者表比較小、可以容忍修復(fù)操作，則依然可以使用它。

提供了大量的特性，包括壓縮表、空間數(shù)據(jù)索引等。

不支持事務(wù)。

不支持行級鎖，只能對整張表加鎖，讀取時會對需要讀到的所有表加共享鎖，寫入時則對表加排它鎖。

會實(shí)時保存數(shù)據(jù)庫表中的總行數(shù)，計(jì)算快。

總結(jié)：

事務(wù)：MyISAM不支持，InnoDB支持。

鎖級別： MyISAM 表級鎖，InnoDB 行級鎖及外鍵約束。

MyISAM存儲表的總行數(shù)；InnoDB不存儲總行數(shù)。

MyISAM采用非聚集索引，B+樹葉子存儲指向數(shù)據(jù)文件的指針。InnoDB主鍵索引采用聚集索引，B+樹葉子存儲數(shù)據(jù)。

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

使用場景：

MyISAM適合：插入不頻繁，查詢非常頻繁，如果執(zhí)行大量的SELECT，MyISAM是更好的選擇，沒有事務(wù)。

InnoDB適合：可靠性要求比較高，或者要求事務(wù)； 表更新和查詢都相當(dāng)?shù)念l繁， 大量的INSERT或UPDATE。

17.數(shù)據(jù)庫分庫分表的原因？

分庫分表的目的在于減少數(shù)據(jù)庫單庫單表的負(fù)擔(dān)，提高查詢性能，縮短查詢時間。

分庫分表分別水平切分和垂直切分。

垂直切分：分為垂直分庫和垂直分表，其中垂直分庫是指根據(jù)業(yè)務(wù)的耦合度，將關(guān)聯(lián)度較低的不同表存儲于不同的庫中，類似于大系統(tǒng)拆分為小系統(tǒng)；垂直分表是指基于數(shù)據(jù)庫表中的列，將不常用的列進(jìn)行劃分成新表，可以使單個表中的數(shù)據(jù)量變少減少跨頁，使得單個頁中字段更多，使內(nèi)存能夠加載更多的數(shù)據(jù)，提高命中率，減少磁盤IO，提高性能。

水平切分：水平切分是根據(jù)表內(nèi)數(shù)據(jù)內(nèi)在的邏輯關(guān)系，將同一個表按不同的條件分散到多個數(shù)據(jù)庫或多個表中，每個表中只包含一部分?jǐn)?shù)據(jù)，從而使得單個表的數(shù)據(jù)量變小，達(dá)到分布式的效果。但只是庫內(nèi)分表，僅僅是解決了單表數(shù)據(jù)過大的問題，并沒有把單表的數(shù)據(jù)分散到不同的物理機(jī)上，因此并不能減輕 MySQL 服務(wù)器的壓力，仍然存在同一個物理機(jī)上的資源競爭和瓶頸，包括 CPU、內(nèi)存、磁盤 IO、網(wǎng)絡(luò)帶寬等。

使用哪種方式分庫分表需要依據(jù)情況而定，比如數(shù)據(jù)庫是因?yàn)楸硖喽斐珊Ａ繑?shù)據(jù)，并且項(xiàng)目的各項(xiàng)業(yè)務(wù)邏輯劃分清晰、低耦合，那么規(guī)則簡單明了、容易實(shí)施的垂直切分必是首選。而如果數(shù)據(jù)庫中的表并不多，但單表的數(shù)據(jù)量很大、或數(shù)據(jù)熱度很高，這種情況之下就應(yīng)該選擇水平切分，水平切分比垂直切分要復(fù)雜一些，它將原本邏輯上屬于一體的數(shù)據(jù)進(jìn)行了物理分割，除了在分割時要對分割的粒度做好評估，考慮數(shù)據(jù)平均和負(fù)載平均，后期也將對項(xiàng)目人員及應(yīng)用程序產(chǎn)生額外的數(shù)據(jù)管理負(fù)擔(dān)。

18.簡述什么是覆蓋索引？

如果一個索引包含所有需要查詢的字段的值，我們就稱 之為“覆蓋索引”。

對于InnoDB存儲引擎來說，如果不是主鍵索引，那么輔助索引的葉子節(jié)點(diǎn)存儲的是主鍵+輔助索引的列值，然后還需要進(jìn)行回表操作。

這樣的話，會降低查詢速度，因此，若使用輔助索引查詢時，若查詢得到的值和需要查詢的結(jié)果列值時對應(yīng)的（或者覆蓋），則可以一直接使用其結(jié)果，不需要進(jìn)行回表操作。

19.簡述三大范式的特點(diǎn)?

第一范式：指數(shù)據(jù)庫表中的每一列都是不可分割的基本數(shù)據(jù)項(xiàng)，同一列中不能有多個值相同，即無重復(fù)的列。

第二范式：滿足第一范式，還要求數(shù)據(jù)庫表中的每個實(shí)例或行必須被唯一標(biāo)識，滿足實(shí)體的屬性完全依賴于主關(guān)鍵字。

第三范式：滿足第二范式，還要求數(shù)據(jù)庫表中不包含其他表中的非主關(guān)鍵字信息，即兩個表中不存在相同的非主關(guān)鍵字信息，否則會造成數(shù)據(jù)冗余。

20.簡述聚簇索引與非聚簇索引（輔助）的區(qū)別？

聚簇索引的葉子節(jié)點(diǎn)存放的是主鍵值和數(shù)據(jù)行，支持覆蓋索引；非聚簇索引的葉子節(jié)點(diǎn)存放的是主鍵值或指向數(shù)據(jù)行的指針。

聚集索引就是以主鍵創(chuàng)建的索引，非聚集索引就是以非主鍵創(chuàng)建的索引。

由于節(jié)子節(jié)點(diǎn)(數(shù)據(jù)頁)只能按照一顆B+樹排序，故一張表只能有一個聚簇索引。輔助索引的存在不影響聚簇索引中數(shù)據(jù)的組織，所以一張表可以有多個輔助索引。

21.簡述事務(wù)的四大特性?

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

一致性：指事務(wù)開始前和結(jié)束后，數(shù)據(jù)庫的完整性約束沒有被破壞。

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

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

22.簡述創(chuàng)建索引的注意事項(xiàng)？

非空字段：索引字段不能有NULL，如果有NULL值將不會包含在索引中。

索引字段越小越好：數(shù)據(jù)庫的數(shù)據(jù)存儲以頁為單位一頁存儲的數(shù)據(jù)越多一次IO操作獲取的數(shù)據(jù)越大效率越高。 唯一、不為空、經(jīng)常被查詢的字段 的字段適合建索引。

取值離散大的字段：（變量各個取值之間的差異程度）的列放到聯(lián)合索引的前面，可以通過count()函數(shù)查看字段的差異值，返回值越大說明字段的唯一值越多字段的離散程度高。

限制創(chuàng)建索引的數(shù)量：對于存在大量更新操作的表，索引一般不超過3個。

23.為什么索引的數(shù)量不能太多？

當(dāng)對表中的數(shù)據(jù)進(jìn)行增加、刪除、修改時，同時需要動態(tài)維護(hù)索引，降低了整體的維護(hù)速度。

索引需要占據(jù)物理空間，如果要建立聚簇索引，那么需要的空間就會更大，因?yàn)闀?shù)據(jù)存儲于葉子節(jié)點(diǎn)。

創(chuàng)建索引和維護(hù)索引要耗費(fèi)時間，這種時間隨著數(shù)據(jù)量的增加而增加。

24.簡述數(shù)據(jù)庫的行級鎖與表鎖？
表鎖：

不會出現(xiàn)死鎖，發(fā)生鎖的沖突幾率高，并發(fā)性低。

存儲引擎在進(jìn)行SQL數(shù)據(jù)讀寫請求前，會對涉及到的表進(jìn)行加鎖。

其中鎖分為共享讀鎖和獨(dú)占寫鎖：讀鎖會阻塞寫，寫鎖會阻塞讀和寫。

行級鎖：

會出現(xiàn)死鎖，發(fā)生鎖的沖突幾率低，并發(fā)性高。

InnoDB引擎支持行鎖，與Oracle不同，MySQL的行鎖是通過索引加載的，也就是說，行鎖是加在索引響應(yīng)的行上的，要是對應(yīng)的SQL語句沒有走索引，則會全表掃描，行鎖則無法實(shí)現(xiàn)，取而代之的是表鎖，此時其它事務(wù)無法對當(dāng)前表進(jìn)行更新或插入操作。

行級鎖注意事項(xiàng)：

行級鎖必須有索引才能實(shí)現(xiàn)，否則會自動鎖全表，那就不是行鎖了。

兩個事務(wù)不能鎖同一個索引。

insert，delete，update在事務(wù)中都會自動默認(rèn)加上排它鎖。

行鎖的適用場景：

避免不可重復(fù)讀的場景。

25.簡述為什么MySQL索引使用B+樹而不用hash表和B樹？

利用Hash需要把數(shù)據(jù)全部加載到內(nèi)存中，如果數(shù)據(jù)量大，是一件很消耗內(nèi)存的事，而采用B+樹，是基于按照節(jié)點(diǎn)分段加載，由此減少內(nèi)存消耗。

和業(yè)務(wù)場景有段，對于唯一查找（查找一個值），Hash確實(shí)更快，但數(shù)據(jù)庫中經(jīng)常查詢多條數(shù)據(jù)，這時候由于B+數(shù)據(jù)的有序性，與葉子節(jié)點(diǎn)又有鏈表相連，他的查詢效率會比Hash快的多。

b+樹的非葉子節(jié)點(diǎn)不保存數(shù)據(jù)，只保存子樹的臨界值（最大或者最小），所以同樣大小的節(jié)點(diǎn)，b+樹相對于b樹能夠有更多的分支，使得這棵樹更加矮胖，查詢時做的IO操作次數(shù)也更少。

26.簡述B樹的結(jié)構(gòu)及特點(diǎn)？
對于一個M階的B樹有以下特征：

第一任何非葉子節(jié)點(diǎn)最多只有M個兒子，且M > 2;

根節(jié)點(diǎn)的兒子數(shù)量范圍為[2,M]；

除根節(jié)點(diǎn) 以外的非葉子節(jié)點(diǎn)的兒子數(shù)量為[M/2，M]，向上取整，M/2是由于當(dāng)某個節(jié)點(diǎn)達(dá)到M個節(jié)點(diǎn)信息時，會進(jìn)行拆分為兩個葉子節(jié)點(diǎn)。

非葉子節(jié)點(diǎn)的關(guān)鍵字?jǐn)?shù)量 = 葉子數(shù)量 - 1；

所有的葉子節(jié)點(diǎn)位于同一層；

k個關(guān)鍵字把節(jié)點(diǎn)拆成k+1段，分別指向k+1個兒子，同時滿足查找樹的大小關(guān)系；

每個節(jié)點(diǎn)除了存儲索引外還保存該索引對應(yīng)數(shù)據(jù)的地址；

27.簡述B+樹的結(jié)構(gòu)及特點(diǎn)？
對于一個M階的B樹有以下特征：

有k個子樹的中間節(jié)點(diǎn)包含有k個元素（B樹中是k-1個元素），每個元素不保存數(shù)據(jù)，只用來索引，所有數(shù)據(jù)都保存在葉子節(jié)點(diǎn)。

所有的葉子結(jié)點(diǎn)中包含了全部元素的信息，及指向含這些元素記錄的指針，且葉子結(jié)點(diǎn)本身依關(guān)鍵字的大小自小而大順序鏈接，形成一個有序的鏈表。

所有的中間節(jié)點(diǎn)元素都同時存在于子節(jié)點(diǎn)，在子節(jié)點(diǎn)元素中是最大（或最小）元素。

由于每個節(jié)點(diǎn)只存索引，因此每個頁存儲的數(shù)據(jù)變多，可減少IO次數(shù)。

28.數(shù)據(jù)庫如何保證事務(wù)的ACID特性？

原子性：使用innodb的undo log（回滾日志），undo log記錄了回滾需要的信息，當(dāng)事務(wù)執(zhí)行失敗或調(diào)用了rollback，導(dǎo)致事務(wù)需要回滾，便可以利用undo log中的信息將數(shù)據(jù)回滾到修改之前的樣子。

隔離性： 使用悲觀鎖和樂觀鎖對事務(wù)處理。

持久性：使用innodb的redo log（重寫日志）， 記錄的是數(shù)據(jù)頁的物理修改，而不是某一行或某幾行修改成怎樣怎樣，它用來恢復(fù)提交后的物理數(shù)據(jù)頁(恢復(fù)數(shù)據(jù)頁，且只能恢復(fù)到最后一次提交的位置);當(dāng)做數(shù)據(jù)修改的時候，不僅在內(nèi)存中操作，還會在redo log中記錄這次操作。當(dāng)事務(wù)提交的時候，會將redo log日志進(jìn)行刷盤(redo log一部分在內(nèi)存中，一部分在磁盤上)。當(dāng)數(shù)據(jù)庫宕機(jī)重啟的時候，會將redo log中的內(nèi)容恢復(fù)到數(shù)據(jù)庫中，再根據(jù)undo log和binlog內(nèi)容決定回滾數(shù)據(jù)還是提交數(shù)據(jù)。

一致性：通過原子性、隔離性、持久性來保證一致性。

29.簡述使用redo的好處?

redo log體積小，畢竟只記錄了哪一頁修改了啥，因此體積小，刷盤快。

redo log是一直往末尾進(jìn)行追加，屬于順序IO。效率顯然比隨機(jī)IO來的快。

30.如何解決數(shù)據(jù)庫高并發(fā)問題？

在web服務(wù)框架中加入緩存。在服務(wù)器與數(shù)據(jù)庫層之間加入緩存層，將高頻訪問的數(shù)據(jù)存入緩存中，減少數(shù)據(jù)庫的讀取負(fù)擔(dān)。

增加數(shù)據(jù)庫索引，進(jìn)而提高查詢速度。（不過索引太多會導(dǎo)致速度變慢，并且數(shù)據(jù)庫的寫入會導(dǎo)致索引的更新，也會導(dǎo)致速度變慢）

主從讀寫分離，讓主服務(wù)器負(fù)責(zé)寫，從服務(wù)器負(fù)責(zé)讀。

將數(shù)據(jù)庫進(jìn)行拆分，使得數(shù)據(jù)庫的表盡可能小，提高查詢的速度。

使用分布式架構(gòu)，分散計(jì)算壓力。

31.簡述聯(lián)合索引的最左匹配原則?

MySQL建立聯(lián)合索引時遵循最左匹配原則，即最左優(yōu)先，在檢索數(shù)據(jù)時從聯(lián)合索引的最左邊開始匹配。

對于聯(lián)合索引而言構(gòu)造B+樹，會依次從左往右按順序比較進(jìn)行鍵值插入，遇到范圍查找就會停止，剩下的字段就會失效無法使用索引。

32.簡述SQL語句的優(yōu)先級順序？

from:需要從哪個數(shù)據(jù)表檢索數(shù)據(jù)

join：聯(lián)合多表查詢返回記錄時，并生成一張臨時表

on：在生成臨時表時使用的條件

where:過濾表中數(shù)據(jù)的條件

group by:如何將上面過濾出的數(shù)據(jù)分組

having:對上面已經(jīng)分組的數(shù)據(jù)進(jìn)行過濾的條件

select:查看結(jié)果集中的哪個列，或列的計(jì)算結(jié)果

order by :按照什么樣的順序來查看返回的數(shù)據(jù)

33.簡述索引失效的情況？

like 以%開頭，索引無效；當(dāng)like前綴沒有%，后綴有%時，索引有效。

or語句前后沒有同時使用索引。當(dāng)or左右查詢字段只有一個是索引，該索引失效，只有當(dāng)or左右查詢字段均為索引時，才會生效。

組合索引，不是使用第一列索引，索引失效。

數(shù)據(jù)類型出現(xiàn)隱式轉(zhuǎn)化。如varchar不加單引號的話可能會自動轉(zhuǎn)換為int型，使索引無效，產(chǎn)生全表掃描。

在索引列上使用 IS NULL 或 IS NOT NULL操作。

在索引字段上使用not，<>，!=。不等于操作符是永遠(yuǎn)不會用到索引的，因此對它的處理只會產(chǎn)生全表掃描。 優(yōu)化方法： key<>0 改為 key>0 or key<0。

對索引字段進(jìn)行計(jì)算操作、字段上使用函數(shù)。

當(dāng)全表掃描速度比索引速度快時，mysql會使用全表掃描，此時索引失效。

如何檢查索引是否失效：

可以使用explain命令加在要分析的sql語句前面，在執(zhí)行結(jié)果中查看key這一列的值，如果為NULL，說明沒有使用索引。

34.簡述什么情況下不應(yīng)該創(chuàng)建索引？

對于那些在查詢中很少使用或者參考的列不應(yīng)該創(chuàng)建索引。這是因?yàn)?#xff0c;既然這些列很少使用到，因此有索引或者無索引，并不能提高查詢速度。相反，由于增加了索引，反而降低了系統(tǒng)的維護(hù)速度和增大了空間需求。

對于那些只有很少數(shù)據(jù)值的列也不應(yīng)該增加索引。這是因?yàn)?#xff0c;由于這些列的取值很少，例如人事表的性別列，在查詢的結(jié)果中，結(jié)果集的數(shù)據(jù)行占了表中數(shù)據(jù)行的很大比例，即需要在表中搜索的數(shù)據(jù)行的比例很大。增加索引，并不能明顯加快檢索速度。

對于那些定義為text, image和bit數(shù)據(jù)類型的列不應(yīng)該增加索引。這是因?yàn)?#xff0c;這些列的數(shù)據(jù)量要么相當(dāng)大，要么取值很少。

當(dāng)修改性能遠(yuǎn)遠(yuǎn)大于檢索性能時，不應(yīng)該創(chuàng)建索引。這是因?yàn)?#xff0c;修改性能和檢索性能是互相矛盾的。

總結(jié)

以上是生活随笔為你收集整理的数据库常见面试题汇总的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。