110道 MySQL面試題及答案（持續更新）

本文轉載自查看原文 2021-12-02 15:20 24355 MySQL面試題大全/ MySQL面試題/ MySQL面試題及答案/ 最新MySQL面試題/ MySQL面試題2021/ MySQL面試題總結

MySQL面試題及答案【最新版】MySQL面試題大全，發現網上很多MySQL面試題及答案整理都沒有答案，所以花了很長時間搜集，本套MySQL面試題大全

如果不背 MySQL面試題的答案，肯定面試會掛！

這套MySQL面試題大全，希望對大家有幫助哈~

1、NOW（）和CURRENT_DATE（）有什么區別？

NOW（）命令用於顯示當前年份，月份，日期，小時，分鍾和秒。

CURRENT_DATE（）僅顯示當前年份，月份和日期。

2、CHAR和VARCHAR的區別？

1.CHAR和VARCHAR類型在存儲和檢索方面有所不同

2.CHAR列長度固定為創建表時聲明的長度，長度值范圍是1到255

當CHAR值被存儲時，它們被用空格填充到特定長度，檢索CHAR值時需刪除尾隨空格。

3、主鍵索引與唯一索引的區別

1、主鍵是一種約束，唯一索引是一種索引，兩者在本質上是不同的。

2、主鍵創建后一定包含一個唯一性索引，唯一性索引並不一定就是主鍵。

3、唯一性索引列允許空值，而主鍵列不允許為空值。

4、主鍵列在創建時，已經默認為空值 ++ 唯一索引了。

5、一個表最多只能創建一個主鍵，但可以創建多個唯一索引。

6、主鍵更適合那些不容易更改的唯一標識，如自動遞增列、身份證號等。

7、主鍵可以被其他表引用為外鍵，而唯一索引不能。？

4、MySQL中有哪些不同的表格？

共有5種類型的表格：

1、 MyISAM

2、 Heap

3、 Merge

4、 INNODB

5、 ISAM

5、SQL的生命周期？

1、應用服務器與數據庫服務器建立一個連接

2、數據庫進程拿到請求sql

3、解析並生成執行計划，執行

4、讀取數據到內存並進行邏輯處理

5、通過步驟一的連接，發送結果到客戶端

6、關掉連接，釋放資源

6、你怎么看到為表格定義的所有索引？

索引是通過以下方式為表格定義的：

SHOW INDEX FROM <tablename>;

2、 B+樹空間利用率更高，可減少I/O次數，磁盤讀寫代價更低。一般來說，索引本身也很大，不可能全部存儲在內存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產生磁盤I/O消耗。B+樹的內部結點並沒有指向關鍵字具體信息的指針，只是作為索引使用，其內部結點比B樹小，盤塊能容納的結點中關鍵字數量更多，一次性讀入內存中可以查找的關鍵字也就越多，相對的，IO讀寫次數也就降低了。而IO讀寫次數是影響索引檢索效率的最大因素；

3、 B+樹的查詢效率更加穩定。B樹搜索有可能會在非葉子結點結束，越靠近根節點的記錄查找時間越短，只要找到關鍵字即可確定記錄的存在，其性能等價於在關鍵字全集內做一次二分查找。而在B+樹中，順序檢索比較明顯，隨機檢索時，任何關鍵字的查找都必須走一條從根節點到葉節點的路，所有關鍵字的查找路徑長度相同，導致每一個關鍵字的查詢效率相當。

4、 B-樹在提高了磁盤IO性能的同時並沒有解決元素遍歷的效率低下的問題。B+樹的葉子節點使用指針順序連接在一起，只要遍歷葉子節點就可以實現整棵樹的遍歷。而且在數據庫中基於范圍的查詢是非常頻繁的，而B樹不支持這樣的操作。

5、增刪文件（節點）時，效率更高。因為B+樹的葉子節點包含所有關鍵字，並以有序的鏈表結構存儲，這樣可很好提高增刪效率。

8、數據庫三大范式是什么

第一范式：每個列都不可以再拆分。

第二范式：在第一范式的基礎上，非主鍵列完全依賴於主鍵，而不能是依賴於主鍵的一部分。

第三范式：在第二范式的基礎上，非主鍵列只依賴於主鍵，不依賴於其他非主鍵。

在設計數據庫結構的時候，要盡量遵守三范式，如果不遵守，必須有足夠的理由。比如性能。事實上我們經常會為了性能而妥協數據庫的設計。

9、怎么優化SQL查詢語句嗎

1、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引

2、用索引可以提高查詢

3、 SELECT子句中避免使用*號，盡量全部大寫SQL

4、應盡量避免在 where 子句中對字段進行 is null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，使用 IS NOT NULL

5、 where 子句中使用 or 來連接條件，也會導致引擎放棄使用索引而進行全表掃描

6、 in 和 not in 也要慎用，否則會導致全表掃描

10、覆蓋索引、回表等這些，了解過嗎？

1、覆蓋索引：查詢列要被所建的索引覆蓋，不必從數據表中讀取，換句話說查詢列要被所使用的索引覆蓋。

2、回表：二級索引無法直接查詢所有列的數據，所以通過二級索引查詢到聚簇索引后，再查詢到想要的數據，這種通過二級索引查詢出來的過程，就叫做回表。

11、MySQL數據庫cpu飆升的話，要怎么處理呢？

排查過程：

1、使用top 命令觀察，確定是MySQLd導致還是其他原因。

2、如果是MySQLd導致的，show processlist，查看session情況，確定是不是有消耗資源的sql在運行。

3、找出消耗高的 sql，看看執行計划是否准確，索引是否缺失，數據量是否太大。

處理：

1、 kill 掉這些線程(同時觀察 cpu 使用率是否下降)，

2、進行相應的調整(比如說加索引、改 sql、改內存參數)

3、重新跑這些 SQL。

其他情況：

也有可能是每個 sql 消耗資源並不多，但是突然之間，有大量的 session 連進來導致 cpu 飆升，這種情況就需要跟應用一起來分析為何連接數會激增，再做出相應的調整，比如說限制連接數等

12、說說對SQL語句優化有哪些方法？（選擇幾條）

1、 Where子句中：where表之間的連接必須寫在其他Where條件之前，那些可以過濾掉最大數量記錄的條件必須寫在Where子句的末尾.HAVING最后。

2、用EXISTS替代IN、用NOT EXISTS替代NOT IN。

3、避免在索引列上使用計算

4、避免在索引列上使用IS NULL和IS NOT NULL

5、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。

6、應盡量避免在 where 子句中對字段進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描

7、應盡量避免在 where 子句中對字段進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描

13、Innodb的事務與日志的實現方式

有多少種日志

innodb兩種日志redo和undo。

日志的存放形式

1、 redo：在頁修改的時候，先寫到 redo log buffer 里面，然后寫到 redo log 的文件系統緩存里面(fwrite)，然后再同步到磁盤文件（ fsync）。

2、 Undo：在 MySQL5.5 之前， undo 只能存放在 ibdata文件里面， 5.6 之后，可以通過設置 innodb_undo_tablespaces 參數把 undo log 存放在 ibdata之外。

事務是如何通過日志來實現的

1、因為事務在修改頁時，要先記 undo，在記 undo 之前要記 undo 的 redo，然后修改數據頁，再記數據頁修改的 redo。 Redo（里面包括 undo 的修改）一定要比數據頁先持久化到磁盤。

2、當事務需要回滾時，因為有 undo，可以把數據頁回滾到前鏡像的狀態，崩潰恢復時，如果 redo log 中事務沒有對應的 commit 記錄，那么需要用 undo把該事務的修改回滾到事務開始之前。

3、如果有 commit 記錄，就用 redo 前滾到該事務完成時並提交掉。

14、非聚簇索引一定會回表查詢嗎？

不一定，如果查詢語句的字段全部命中了索引，那么就不必再進行回表查詢（哈哈，覆蓋索引就是這么回事）。

舉個簡單的例子，假設我們在學生表的上建立了索引，那么當進行select age from student where age < 20的查詢時，在索引的葉子節點上，已經包含了age信息，不會再次進行回表查詢。

15、Hash索引和B+樹所有有什么區別或者說優劣呢?

1、首先要知道Hash索引和B+樹索引的底層實現原理：

2、 hash索引底層就是hash表，進行查找時，調用一次hash函數就可以獲取到相應的鍵值，之后進行回表查詢獲得實際數據。B+樹底層實現是多路平衡查找樹。對於每一次的查詢都是從根節點出發，查找到葉子節點方可以獲得所查鍵值，然后根據查詢判斷是否需要回表查詢數據。

那么可以看出他們有以下的不同：

1、 hash索引進行等值查詢更快(一般情況下)，但是卻無法進行范圍查詢。

2、因為在hash索引中經過hash函數建立索引之后，索引的順序與原順序無法保持一致，不能支持范圍查詢。而B+樹的的所有節點皆遵循(左節點小於父節點，右節點大於父節點，多叉樹也類似)，天然支持范圍。

3、 hash索引不支持使用索引進行排序，原理同上。

4、 hash索引不支持模糊查詢以及多列索引的最左前綴匹配。原理也是因為hash函數的不可預測。AAAA和AAAAB的索引沒有相關性。

5、 hash索引任何時候都避免不了回表查詢數據，而B+樹在符合某些條件(聚簇索引，覆蓋索引等)的時候可以只通過索引完成查詢。

6、 hash索引雖然在等值查詢上較快，但是不穩定。性能不可預測，當某個鍵值存在大量重復的時候，發生hash碰撞，此時效率可能極差。而B+樹的查詢效率比較穩定，對於所有的查詢都是從根節點到葉子節點，且樹的高度較低。

7、因此，在大多數情況下，直接選擇B+樹索引可以獲得穩定且較好的查詢速度。而不需要使用hash索引。

16、select for update有什么含義，會鎖表還是鎖行還是其他。

select for update 含義

select查詢語句是不會加鎖的，但是select for update除了有查詢的作用外，還會加鎖呢，而且它是悲觀鎖哦。至於加了是行鎖還是表鎖，這就要看是不是用了索引/主鍵啦。

沒用索引/主鍵的話就是表鎖，否則就是是行鎖。

select for update 加鎖驗證

表結構：

//id 為主鍵，name為唯一索引 CREATE TABLE `account` ( `id` int(11) NOT NULL AUTO_INCREMENT, `name` varchar(255) DEFAULT NULL, `balance` int(11) DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_name` (`name`) USING BTREE ) ENGINE=InnoDB AUTO_INCREMENT=1570068 DEFAULT CHARSET=utf8

id為主鍵，select for update 1270070這條記錄時，再開一個事務對該記錄更新，發現更新阻塞啦，其實是加鎖了。如下圖：

我們再開一個事務對另外一條記錄1270071更新，發現更新成功，因此，如果查詢條件用了索引/主鍵，會加行鎖~

我們繼續一路向北吧，換普通字段balance吧，發現又阻塞了。因此，沒用索引/主鍵的話，select for update加的就是表鎖

17、你們數據庫是否支持emoji表情存儲，如果不支持，如何操作？

更換字符集utf8-->utf8mb4

18、索引的數據結構（b樹，hash）

索引的數據結構和具體存儲引擎的實現有關，在MySQL中使用較多的索引有Hash索引，B+樹索引等，而我們經常使用的InnoDB存儲引擎的默認索引實現為：B+樹索引。對於哈希索引來說，底層的數據結構就是哈希表，因此在絕大多數需求為單條記錄查詢的時候，可以選擇哈希索引，查詢性能最快；其余大部分場景，建議選擇BTree索引。

B樹索引

MySQL通過存儲引擎取數據，基本上90%的人用的就是InnoDB了，按照實現方式分，InnoDB的索引類型目前只有兩種：BTREE（B樹）索引和HASH索引。B樹索引是MySQL數據庫中使用最頻繁的索引類型，基本所有存儲引擎都支持BTree索引。通常我們說的索引不出意外指的就是（B樹）索引（實際是用B+樹實現的，因為在查看表索引時，MySQL一律打印BTREE，所以簡稱為B樹索引）

![99_1.png][99_1.png]

查詢方式：

1、主鍵索引區:PI(關聯保存的時數據的地址)按主鍵查詢,

2、普通索引區:si(關聯的id的地址,然后再到達上面的地址)。所以按主鍵查詢,速度最快

B+tree性質：

1、 n棵子tree的節點包含n個關鍵字，不用來保存數據而是保存數據的索引。

2、所有的葉子結點中包含了全部關鍵字的信息，及指向含這些關鍵字記錄的指針，且葉子結點本身依關鍵字的大小自小而大順序鏈接。

3、所有的非終端結點可以看成是索引部分，結點中僅含其子樹中的最大（或最小）關鍵字。

4、 B+ 樹中，數據對象的插入和刪除僅在葉節點上進行。

5、 B+樹有2個頭指針，一個是樹的根節點，一個是最小關鍵碼的葉節點。

哈希索引

簡要說下，類似於數據結構中簡單實現的HASH表（散列表）一樣，當我們在MySQL中用哈希索引時，主要就是通過Hash算法（常見的Hash算法有直接定址法、平方取中法、折疊法、除數取余法、隨機數法），將數據庫字段數據轉換成定長的Hash值，與這條數據的行指針一並存入Hash表的對應位置；如果發生Hash碰撞（兩個不同關鍵字的Hash值相同），則在對應Hash鍵下以鏈表形式存儲。當然這只是簡略模擬圖。

![99_2.png][99_2.png]

19、最左匹配原則？

在創建聯合索引時候，一般需要遵循最左匹配原則。即聯合索引中的屬性識別度最高的放在查詢語句的最前面。

20、對於關系型數據庫而言，索引是相當重要的概念，請回答有關索引的幾個問題：

1.索引的目的是什么？

快速訪問數據表中的特定信息，提高檢索速度

創建唯一性索引，保證數據庫表中每一行數據的唯一性。

加速表和表之間的連接

使用分組和排序子句進行數據檢索時，可以顯著減少查詢中分組和排序的時間

2.索引對數據庫系統的負面影響是什么？

負面影響：

創建索引和維護索引需要耗費時間，這個時間隨着數據量的增加而增加；索引需要占用物理空間，不光是表需要占用數據空間，每個索引也需要占用物理空間；當對表進行增、刪、改、的時候索引也要動態維護，這樣就降低了數據的維護速度。

3.為數據表建立索引的原則有哪些？

在最頻繁使用的、用以縮小查詢范圍的字段上建立索引。

在頻繁使用的、需要排序的字段上建立索引

4.什么情況下不宜建立索引？

對於查詢中很少涉及的列或者重復值比較多的列，不宜建立索引。

對於一些特殊的數據類型，不宜建立索引，比如文本字段（text）等

21、什么是最左前綴原則？什么是最左匹配原則？

最左前綴原則，就是最左優先，在創建多列索引時，要根據業務需求，where子句中使用最頻繁的一列放在最左邊。

當我們創建一個組合索引的時候，如(k1,k2,k3)，相當於創建了（k1）、(k1,k2)和(k1,k2,k3)三個索引，這就是最左匹配原則。。

22、myisamchk是用來做什么的？

它用來壓縮MyISAM表，這減少了磁盤或內存使用。

23、說說分庫與分表的設計

分庫分表方案，分庫分表中間件，分庫分表可能遇到的問題

「分庫分表方案:」

1、水平分庫：以字段為依據，按照一定策略（hash、range等），將一個庫中的數據拆分到多個庫中。

2、水平分表：以字段為依據，按照一定策略（hash、range等），將一個表中的數據拆分到多個表中。

3、垂直分庫：以表為依據，按照業務歸屬不同，將不同的表拆分到不同的庫中。

4、垂直分表：以字段為依據，按照字段的活躍性，將表中字段拆到不同的表（主表和擴展表）中。

「常用的分庫分表中間件：」

1、 sharding-jdbc（當當）

2、 Mycat

3、 TDDL（淘寶）

4、 Oceanus(58同城數據庫中間件)

5、 vitess（谷歌開發的數據庫中間件）

6、 Atlas(Qihoo 360)

「分庫分表可能遇到的問題」

1、事務問題：需要用分布式事務啦

2、跨節點Join的問題：解決這一問題可以分兩次查詢實現

3、跨節點的count,order by,group by以及聚合函數問題：分別在各個節點上得到結果后在應用程序端進行合並。

4、數據遷移，容量規划，擴容等問題

5、 ID問題：數據庫被切分后，不能再依賴數據庫自身的主鍵生成機制啦，最簡單可以考慮UUID

6、跨分片的排序分頁問題（后台加大pagesize處理？）

24、什么情況下設置了索引但無法使用

1.以“%”開頭的LIKE語句，模糊匹配

2\、OR語句前后沒有同時使用索引

3\、數據類型出現隱式轉化（如varchar不加單引號的話可能會自動轉換為int型）

25、如何刪除索引

根據索引名刪除普通索引、唯一索引、全文索引：alter table 表名 drop KEY 索引名

alter table user_index drop KEY name; alter table user_index drop KEY id_card; alter table user_index drop KEY information;

刪除主鍵索引：alter table 表名 drop primary key（因為主鍵只有一個）。這里值得注意的是，如果主鍵自增長，那么不能直接執行此操作（自增長依賴於主鍵索引）：

![99_3.png][99_3.png]

需要取消自增長再行刪除：

alter table user_index -- 重新定義字段 MODIFY id int, drop PRIMARY KEY

但通常不會刪除主鍵，因為設計主鍵一定與業務邏輯無關。

26、什么是數據庫連接池?為什么需要數據庫連接池呢?

連接池基本原理：

數據庫連接池原理：在內部對象池中，維護一定數量的數據庫連接，並對外暴露數據庫連接的獲取和返回方法。

應用程序和數據庫建立連接的過程：

1、通過TCP協議的三次握手和數據庫服務器建立連接

2、發送數據庫用戶賬號密碼，等待數據庫驗證用戶身份

3、完成身份驗證后，系統可以提交SQL語句到數據庫執行

4、把連接關閉，TCP四次揮手告別。

數據庫連接池好處：

1、資源重用 (連接復用)

2、更快的系統響應速度

3、新的資源分配手段

4、統一的連接管理，避免數據庫連接泄漏

27、列對比運算符是什么？

在SELECT語句的列比較中使用=，<>，<=，<，> =，>，<<，>>，<=>，AND，OR或LIKE運算符。

28、按照鎖的粒度分，數據庫鎖有哪些呢？鎖機制與InnoDB鎖算法

按鎖粒度分有：表鎖，頁鎖，行鎖

按鎖機制分有：樂觀鎖，悲觀鎖

29、LIKE聲明中的％和_是什么意思？

％對應於0個或更多字符，_只是LIKE語句中的一個字符。

如何在Unix和MySQL時間戳之間進行轉換？

UNIX_TIMESTAMP是從MySQL時間戳轉換為Unix時間戳的命令

FROM_UNIXTIME是從Unix時間戳轉換為MySQL時間戳的命令

30、如何定位及優化SQL語句的性能問題？創建的索引有沒有被使用到?或者說怎么才可以知道這條語句運行很慢的原因？

對於低性能的SQL語句的定位，最重要也是最有效的方法就是使用執行計划，MySQL提供了explain命令來查看語句的執行計划。我們知道，不管是哪種數據庫，或者是哪種數據庫引擎，在對一條SQL語句進行執行的過程中都會做很多相關的優化，對於查詢語句，最重要的優化方式就是使用索引。而執行計划，就是顯示數據庫引擎對於SQL語句的執行的詳細情況，其中包含了是否使用索引，使用什么索引，使用的索引的相關信息等。

執行計划包含的信息 id 有一組數字組成。表示一個查詢中各個子查詢的執行順序;

1、 id相同執行順序由上至下。

2、 id不同，id值越大優先級越高，越先被執行。

3、 id為null時表示一個結果集，不需要使用它查詢，常出現在包含union等查詢語句中。

select_type 每個子查詢的查詢類型，一些常見的查詢類型。

table 查詢的數據表，當從衍生表中查數據時會顯示 x 表示對應的執行計划id partitions 表分區、表創建的時候可以指定通過那個列進行表分區。舉個例子：

create table tmp ( id int unsigned not null AUTO_INCREMENT, name varchar(255), PRIMARY KEY (id) ) engine = innodb partition by key (id) partitions 5;

type(非常重要，可以看到有沒有走索引) 訪問類型

1、 ALL 掃描全表數據

2、 index 遍歷索引

3、 range 索引范圍查找

4、 index_subquery 在子查詢中使用 ref

5、 unique_subquery 在子查詢中使用 eq_ref

6、 ref_or_null 對Null進行索引的優化的 ref

7、 fulltext 使用全文索引

8、 ref 使用非唯一索引查找數據

9、 eq_ref 在join查詢中使用PRIMARY KEYorUNIQUE NOT NULL索引關聯。

10、 possible_keys 可能使用的索引，注意不一定會使用。查詢涉及到的字段上若存在索引，則該索引將被列出來。當該列為 NULL時就要考慮當前的SQL是否需要優化了。

11、 key 顯示MySQL在查詢中實際使用的索引，若沒有使用索引，顯示為NULL。

12、 TIPS:查詢中若使用了覆蓋索引(覆蓋索引：索引的數據覆蓋了需要查詢的所有數據)，則該索引僅出現在key列表中

13、 key_length 索引長度

14、 ref 表示上述表的連接匹配條件，即哪些列或常量被用於查找索引列上的值

15、 rows 返回估算的結果集數目，並不是一個准確的值。

16、 extra 的信息非常豐富，常見的有：

17、 Using index 使用覆蓋索引

18、 Using where 使用了用where子句來過濾結果集

19、 Using filesort 使用文件排序，使用非索引列進行排序時出現，非常消耗性能，盡量優化。

20、 Using temporary 使用了臨時表 sql優化的目標可以參考阿里開發手冊