110道 MySQL面试题及答案 （持续更新）
MySQL面試題及答案 【最新版】MySQL面試題大全，發(fā)現(xiàn)網(wǎng)上很多MySQL面試題及答案整理都沒有答案，所以花了很長時間搜集，本套MySQL面試題大全
如果不背 MySQL面試題的答案，肯定面試會掛！
這套MySQL面試題大全，希望對大家有幫助哈~
博主已將以下這些面試題整理成了一個面試手冊，是PDF版的
1、NOW（）和CURRENT_DATE（）有什么區(qū)別？
NOW（）命令用于顯示當(dāng)前年份，月份，日期，小時，分鐘和秒。
CURRENT_DATE（）僅顯示當(dāng)前年份，月份和日期。
2、CHAR和VARCHAR的區(qū)別？
1.CHAR和VARCHAR類型在存儲和檢索方面有所不同
2.CHAR列長度固定為創(chuàng)建表時聲明的長度，長度值范圍是1到255
當(dāng)CHAR值被存儲時，它們被用空格填充到特定長度，檢索CHAR值時需刪除尾隨空格。
3、主鍵索引與唯一索引的區(qū)別
1、?主鍵是一種約束，唯一索引是一種索引，兩者在本質(zhì)上是不同的。
2、?主鍵創(chuàng)建后一定包含一個唯一性索引，唯一性索引并不一定就是主鍵。
3、?唯一性索引列允許空值，而主鍵列不允許為空值。
4、?主鍵列在創(chuàng)建時，已經(jīng)默認(rèn)為空值 ++ 唯一索引了。
5、?一個表最多只能創(chuàng)建一個主鍵，但可以創(chuàng)建多個唯一索引。
6、?主鍵更適合那些不容易更改的唯一標(biāo)識，如自動遞增列、身份證號等。
7、?主鍵可以被其他表引用為外鍵，而唯一索引不能。 ？
4、MySQL中有哪些不同的表格？
共有5種類型的表格：
1、?MyISAM
2、?Heap
3、?Merge
4、?INNODB
5、?ISAM
5、SQL的生命周期？
1、?應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器建立一個連接
2、?數(shù)據(jù)庫進(jìn)程拿到請求sql
3、?解析并生成執(zhí)行計劃，執(zhí)行
4、?讀取數(shù)據(jù)到內(nèi)存并進(jìn)行邏輯處理
5、?通過步驟一的連接，發(fā)送結(jié)果到客戶端
6、?關(guān)掉連接，釋放資源
6、你怎么看到為表格定義的所有索引？
索引是通過以下方式為表格定義的：
SHOW INDEX FROM <tablename>;
7、數(shù)據(jù)庫為什么使用B+樹而不是B樹
1、?B樹只適合隨機檢索，而B+樹同時支持隨機檢索和順序檢索；
2、?B+樹空間利用率更高，可減少I/O次數(shù)，磁盤讀寫代價更低。一般來說，索引本身也很大，不可能全部存儲在內(nèi)存中，因此索引往往以索引文件的形式存儲的磁盤上。這樣的話，索引查找過程中就要產(chǎn)生磁盤I/O消耗。B+樹的內(nèi)部結(jié)點并沒有指向關(guān)鍵字具體信息的指針，只是作為索引使用，其內(nèi)部結(jié)點比B樹小，盤塊能容納的結(jié)點中關(guān)鍵字?jǐn)?shù)量更多，一次性讀入內(nèi)存中可以查找的關(guān)鍵字也就越多，相對的，IO讀寫次數(shù)也就降低了。而IO讀寫次數(shù)是影響索引檢索效率的最大因素；
3、?B+樹的查詢效率更加穩(wěn)定。B樹搜索有可能會在非葉子結(jié)點結(jié)束，越靠近根節(jié)點的記錄查找時間越短，只要找到關(guān)鍵字即可確定記錄的存在，其性能等價于在關(guān)鍵字全集內(nèi)做一次二分查找。而在B+樹中，順序檢索比較明顯，隨機檢索時，任何關(guān)鍵字的查找都必須走一條從根節(jié)點到葉節(jié)點的路，所有關(guān)鍵字的查找路徑長度相同，導(dǎo)致每一個關(guān)鍵字的查詢效率相當(dāng)。
4、?B-樹在提高了磁盤IO性能的同時并沒有解決元素遍歷的效率低下的問題。B+樹的葉子節(jié)點使用指針順序連接在一起，只要遍歷葉子節(jié)點就可以實現(xiàn)整棵樹的遍歷。而且在數(shù)據(jù)庫中基于范圍的查詢是非常頻繁的，而B樹不支持這樣的操作。
5、?增刪文件（節(jié)點）時，效率更高。因為B+樹的葉子節(jié)點包含所有關(guān)鍵字，并以有序的鏈表結(jié)構(gòu)存儲，這樣可很好提高增刪效率。
8、數(shù)據(jù)庫三大范式是什么
第一范式：每個列都不可以再拆分。
第二范式：在第一范式的基礎(chǔ)上，非主鍵列完全依賴于主鍵，而不能是依賴于主鍵的一部分。
第三范式：在第二范式的基礎(chǔ)上，非主鍵列只依賴于主鍵，不依賴于其他非主鍵。
在設(shè)計數(shù)據(jù)庫結(jié)構(gòu)的時候，要盡量遵守三范式，如果不遵守，必須有足夠的理由。比如性能。事實上我們經(jīng)常會為了性能而妥協(xié)數(shù)據(jù)庫的設(shè)計。
9、怎么優(yōu)化SQL查詢語句嗎
1、?對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引
2、?用索引可以提高查詢
3、?SELECT子句中避免使用*號，盡量全部大寫SQL
4、?應(yīng)盡量避免在 where 子句中對字段進(jìn)行 is null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描，使用 IS NOT NULL
5、?where 子句中使用 or 來連接條件，也會導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描
6、?in 和 not in 也要慎用，否則會導(dǎo)致全表掃描
10、覆蓋索引、回表等這些，了解過嗎？
1、?覆蓋索引： 查詢列要被所建的索引覆蓋，不必從數(shù)據(jù)表中讀取，換句話說查詢列要被所使用的索引覆蓋。
2、?回表：二級索引無法直接查詢所有列的數(shù)據(jù)，所以通過二級索引查詢到聚簇索引后，再查詢到想要的數(shù)據(jù)，這種通過二級索引查詢出來的過程，就叫做回表。
11、MySQL數(shù)據(jù)庫cpu飆升的話，要怎么處理呢？
排查過程：
1、?使用top 命令觀察，確定是MySQLd導(dǎo)致還是其他原因。
2、?如果是MySQLd導(dǎo)致的，show processlist，查看session情況，確定是不是有消耗資源的sql在運行。
3、?找出消耗高的 sql，看看執(zhí)行計劃是否準(zhǔn)確， 索引是否缺失，數(shù)據(jù)量是否太大。
處理：
1、?kill 掉這些線程(同時觀察 cpu 使用率是否下降)，
2、?進(jìn)行相應(yīng)的調(diào)整(比如說加索引、改 sql、改內(nèi)存參數(shù))
3、?重新跑這些 SQL。
其他情況：
也有可能是每個 sql 消耗資源并不多，但是突然之間，有大量的 session 連進(jìn)來導(dǎo)致 cpu 飆升，這種情況就需要跟應(yīng)用一起來分析為何連接數(shù)會激增，再做出相應(yīng)的調(diào)整，比如說限制連接數(shù)等
12、說說對SQL語句優(yōu)化有哪些方法？（選擇幾條）
1、?Where子句中：where表之間的連接必須寫在其他Where條件之前，那些可以過濾掉最大數(shù)量記錄的條件必須寫在Where子句的末尾.HAVING最后。
2、?用EXISTS替代IN、用NOT EXISTS替代NOT IN。
3、?避免在索引列上使用計算
4、?避免在索引列上使用IS NULL和IS NOT NULL
5、?對查詢進(jìn)行優(yōu)化，應(yīng)盡量避免全表掃描，首先應(yīng)考慮在 where 及 order by 涉及的列上建立索引。
6、?應(yīng)盡量避免在 where 子句中對字段進(jìn)行 null 值判斷，否則將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描
7、?應(yīng)盡量避免在 where 子句中對字段進(jìn)行表達(dá)式操作，這將導(dǎo)致引擎放棄使用索引而進(jìn)行全表掃描
13、Innodb的事務(wù)與日志的實現(xiàn)方式
有多少種日志
innodb兩種日志redo和undo。
日志的存放形式
1、?redo：在頁修改的時候，先寫到 redo log buffer 里面， 然后寫到 redo log 的文件系統(tǒng)緩存里面(fwrite)，然后再同步到磁盤文件（ fsync）。
2、?Undo：在 MySQL5.5 之前， undo 只能存放在 ibdata文件里面， 5.6 之后，可以通過設(shè)置 innodb_undo_tablespaces 參數(shù)把 undo log 存放在 ibdata之外。
事務(wù)是如何通過日志來實現(xiàn)的
1、?因為事務(wù)在修改頁時，要先記 undo，在記 undo 之前要記 undo 的 redo， 然后修改數(shù)據(jù)頁，再記數(shù)據(jù)頁修改的 redo。 Redo（里面包括 undo 的修改） 一定要比數(shù)據(jù)頁先持久化到磁盤。
2、?當(dāng)事務(wù)需要回滾時，因為有 undo，可以把數(shù)據(jù)頁回滾到前鏡像的 狀態(tài)，崩潰恢復(fù)時，如果 redo log 中事務(wù)沒有對應(yīng)的 commit 記錄，那么需要用 undo把該事務(wù)的修改回滾到事務(wù)開始之前。
3、?如果有 commit 記錄，就用 redo 前滾到該事務(wù)完成時并提交掉。
14、非聚簇索引一定會回表查詢嗎？
不一定，如果查詢語句的字段全部命中了索引，那么就不必再進(jìn)行回表查詢（哈哈，覆蓋索引就是這么回事）。
舉個簡單的例子，假設(shè)我們在學(xué)生表的上建立了索引，那么當(dāng)進(jìn)行select age from student where age < 20的查詢時，在索引的葉子節(jié)點上，已經(jīng)包含了age信息，不會再次進(jìn)行回表查詢。
15、Hash索引和B+樹所有有什么區(qū)別或者說優(yōu)劣呢?
1、?首先要知道Hash索引和B+樹索引的底層實現(xiàn)原理：
2、?hash索引底層就是hash表，進(jìn)行查找時，調(diào)用一次hash函數(shù)就可以獲取到相應(yīng)的鍵值，之后進(jìn)行回表查詢獲得實際數(shù)據(jù)。B+樹底層實現(xiàn)是多路平衡查找樹。對于每一次的查詢都是從根節(jié)點出發(fā)，查找到葉子節(jié)點方可以獲得所查鍵值，然后根據(jù)查詢判斷是否需要回表查詢數(shù)據(jù)。
那么可以看出他們有以下的不同：
1、?hash索引進(jìn)行等值查詢更快(一般情況下)，但是卻無法進(jìn)行范圍查詢。
2、?因為在hash索引中經(jīng)過hash函數(shù)建立索引之后，索引的順序與原順序無法保持一致，不能支持范圍查詢。而B+樹的的所有節(jié)點皆遵循(左節(jié)點小于父節(jié)點，右節(jié)點大于父節(jié)點，多叉樹也類似)，天然支持范圍。
3、?hash索引不支持使用索引進(jìn)行排序，原理同上。
4、?hash索引不支持模糊查詢以及多列索引的最左前綴匹配。原理也是因為hash函數(shù)的不可預(yù)測。AAAA和AAAAB的索引沒有相關(guān)性。
5、?hash索引任何時候都避免不了回表查詢數(shù)據(jù)，而B+樹在符合某些條件(聚簇索引，覆蓋索引等)的時候可以只通過索引完成查詢。
6、?hash索引雖然在等值查詢上較快，但是不穩(wěn)定。性能不可預(yù)測，當(dāng)某個鍵值存在大量重復(fù)的時候，發(fā)生hash碰撞，此時效率可能極差。而B+樹的查詢效率比較穩(wěn)定，對于所有的查詢都是從根節(jié)點到葉子節(jié)點，且樹的高度較低。
7、?因此，在大多數(shù)情況下，直接選擇B+樹索引可以獲得穩(wěn)定且較好的查詢速度。而不需要使用hash索引。
16、select for update有什么含義，會鎖表還是鎖行還是其他。
select for update 含義
select查詢語句是不會加鎖的，但是select for update除了有查詢的作用外，還會加鎖呢，而且它是悲觀鎖哦。至于加了是行鎖還是表鎖，這就要看是不是用了索引/主鍵啦。
沒用索引/主鍵的話就是表鎖，否則就是是行鎖。
select for update 加鎖驗證
表結(jié)構(gòu)：
//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這條記錄時，再開一個事務(wù)對該記錄更新，發(fā)現(xiàn)更新阻塞啦，其實是加鎖了。如下圖：
我們再開一個事務(wù)對另外一條記錄1270071更新，發(fā)現(xiàn)更新成功，因此，如果查詢條件用了索引/主鍵，會加行鎖~
我們繼續(xù)一路向北吧，換普通字段balance吧，發(fā)現(xiàn)又阻塞了。因此，沒用索引/主鍵的話，select for update加的就是表鎖
17、你們數(shù)據(jù)庫是否支持emoji表情存儲，如果不支持，如何操作？
更換字符集utf8-->utf8mb4
18、索引的數(shù)據(jù)結(jié)構(gòu)（b樹，hash）
索引的數(shù)據(jù)結(jié)構(gòu)和具體存儲引擎的實現(xiàn)有關(guān)，在MySQL中使用較多的索引有Hash索引，B+樹索引等，而我們經(jīng)常使用的InnoDB存儲引擎的默認(rèn)索引實現(xiàn)為：B+樹索引。對于哈希索引來說，底層的數(shù)據(jù)結(jié)構(gòu)就是哈希表，因此在絕大多數(shù)需求為單條記錄查詢的時候，可以選擇哈希索引，查詢性能最快；其余大部分場景，建議選擇BTree索引。
B樹索引
MySQL通過存儲引擎取數(shù)據(jù)，基本上90%的人用的就是InnoDB了，按照實現(xiàn)方式分，InnoDB的索引類型目前只有兩種：BTREE（B樹）索引和HASH索引。B樹索引是MySQL數(shù)據(jù)庫中使用最頻繁的索引類型，基本所有存儲引擎都支持BTree索引。通常我們說的索引不出意外指的就是（B樹）索引（實際是用B+樹實現(xiàn)的，因為在查看表索引時，MySQL一律打印BTREE，所以簡稱為B樹索引）
![99_1.png][99_1.png]
查詢方式：
1、?主鍵索引區(qū):PI(關(guān)聯(lián)保存的時數(shù)據(jù)的地址)按主鍵查詢,
2、?普通索引區(qū):si(關(guān)聯(lián)的id的地址,然后再到達(dá)上面的地址)。所以按主鍵查詢,速度最快
B+tree性質(zhì)：
1、?n棵子tree的節(jié)點包含n個關(guān)鍵字，不用來保存數(shù)據(jù)而是保存數(shù)據(jù)的索引。
2、?所有的葉子結(jié)點中包含了全部關(guān)鍵字的信息，及指向含這些關(guān)鍵字記錄的指針，且葉子結(jié)點本身依關(guān)鍵字的大小自小而大順序鏈接。
3、?所有的非終端結(jié)點可以看成是索引部分，結(jié)點中僅含其子樹中的最大（或最小）關(guān)鍵字。
4、?B+ 樹中，數(shù)據(jù)對象的插入和刪除僅在葉節(jié)點上進(jìn)行。
5、?B+樹有2個頭指針，一個是樹的根節(jié)點，一個是最小關(guān)鍵碼的葉節(jié)點。
哈希索引
簡要說下，類似于數(shù)據(jù)結(jié)構(gòu)中簡單實現(xiàn)的HASH表（散列表）一樣，當(dāng)我們在MySQL中用哈希索引時，主要就是通過Hash算法（常見的Hash算法有直接定址法、平方取中法、折疊法、除數(shù)取余法、隨機數(shù)法），將數(shù)據(jù)庫字段數(shù)據(jù)轉(zhuǎn)換成定長的Hash值，與這條數(shù)據(jù)的行指針一并存入Hash表的對應(yīng)位置；如果發(fā)生Hash碰撞（兩個不同關(guān)鍵字的Hash值相同），則在對應(yīng)Hash鍵下以鏈表形式存儲。當(dāng)然這只是簡略模擬圖。
![99_2.png][99_2.png]
19、最左匹配原則？
在創(chuàng)建聯(lián)合索引時候，一般需要遵循最左匹配原則。即聯(lián)合索引中的屬性識別度最高的放在查詢語句的最前面。
20、對于關(guān)系型數(shù)據(jù)庫而言，索引是相當(dāng)重要的概念，請回答有關(guān)索引的幾個問題：
1.索引的目的是什么？
快速訪問數(shù)據(jù)表中的特定信息，提高檢索速度
創(chuàng)建唯一性索引，保證數(shù)據(jù)庫表中每一行數(shù)據(jù)的唯一性。
加速表和表之間的連接
使用分組和排序子句進(jìn)行數(shù)據(jù)檢索時，可以顯著減少查詢中分組和排序的時間
2.索引對數(shù)據(jù)庫系統(tǒng)的負(fù)面影響是什么？
負(fù)面影響：
創(chuàng)建索引和維護(hù)索引需要耗費時間，這個時間隨著數(shù)據(jù)量的增加而增加；索引需要占用物理空間，不光是表需要占用數(shù)據(jù)空間，每個索引也需要占用物理空間；當(dāng)對表進(jìn)行增、刪、改、的時候索引也要動態(tài)維護(hù)，這樣就降低了數(shù)據(jù)的維護(hù)速度。
3.為數(shù)據(jù)表建立索引的原則有哪些？
在最頻繁使用的、用以縮小查詢范圍的字段上建立索引。
在頻繁使用的、需要排序的字段上建立索引
4.什么情況下不宜建立索引？
對于查詢中很少涉及的列或者重復(fù)值比較多的列，不宜建立索引。
對于一些特殊的數(shù)據(jù)類型，不宜建立索引，比如文本字段（text）等
21、什么是最左前綴原則？什么是最左匹配原則？
最左前綴原則，就是最左優(yōu)先，在創(chuàng)建多列索引時，要根據(jù)業(yè)務(wù)需求，where子句中使用最頻繁的一列放在最左邊。
當(dāng)我們創(chuàng)建一個組合索引的時候，如(k1,k2,k3)，相當(dāng)于創(chuàng)建了（k1）、(k1,k2)和(k1,k2,k3)三個索引，這就是最左匹配原則。。
22、myisamchk是用來做什么的？
它用來壓縮MyISAM表，這減少了磁盤或內(nèi)存使用。
23、說說分庫與分表的設(shè)計
分庫分表方案，分庫分表中間件，分庫分表可能遇到的問題
「分庫分表方案:」
1、?水平分庫：以字段為依據(jù)，按照一定策略（hash、range等），將一個庫中的數(shù)據(jù)拆分到多個庫中。
2、?水平分表：以字段為依據(jù)，按照一定策略（hash、range等），將一個表中的數(shù)據(jù)拆分到多個表中。
3、?垂直分庫：以表為依據(jù)，按照業(yè)務(wù)歸屬不同，將不同的表拆分到不同的庫中。
4、?垂直分表：以字段為依據(jù)，按照字段的活躍性，將表中字段拆到不同的表（主表和擴展表）中。
「常用的分庫分表中間件：」
1、?sharding-jdbc（當(dāng)當(dāng)）
2、?Mycat
3、?TDDL（淘寶）
4、?Oceanus(58同城數(shù)據(jù)庫中間件)
5、?vitess（谷歌開發(fā)的數(shù)據(jù)庫中間件）
6、?Atlas(Qihoo 360)
「分庫分表可能遇到的問題」
1、?事務(wù)問題：需要用分布式事務(wù)啦
2、?跨節(jié)點Join的問題：解決這一問題可以分兩次查詢實現(xiàn)
3、?跨節(jié)點的count,order by,group by以及聚合函數(shù)問題：分別在各個節(jié)點上得到結(jié)果后在應(yīng)用程序端進(jìn)行合并。
4、?數(shù)據(jù)遷移，容量規(guī)劃，擴容等問題
5、?ID問題：數(shù)據(jù)庫被切分后，不能再依賴數(shù)據(jù)庫自身的主鍵生成機制啦，最簡單可以考慮UUID
6、?跨分片的排序分頁問題（后臺加大pagesize處理？）
24、什么情況下設(shè)置了索引但無法使用
1.以“%”開頭的LIKE語句，模糊匹配
2\、OR語句前后沒有同時使用索引
3\、數(shù)據(jù)類型出現(xiàn)隱式轉(zhuǎn)化（如varchar不加單引號的話可能會自動轉(zhuǎn)換為int型）
25、如何刪除索引
根據(jù)索引名刪除普通索引、唯一索引、全文索引：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（因為主鍵只有一個）。這里值得注意的是，如果主鍵自增長，那么不能直接執(zhí)行此操作（自增長依賴于主鍵索引）：
![99_3.png][99_3.png]
需要取消自增長再行刪除：
alter table user_index -- 重新定義字段 MODIFY id int, drop PRIMARY KEY
但通常不會刪除主鍵，因為設(shè)計主鍵一定與業(yè)務(wù)邏輯無關(guān)。
26、什么是數(shù)據(jù)庫連接池?為什么需要數(shù)據(jù)庫連接池呢?
連接池基本原理：
數(shù)據(jù)庫連接池原理：在內(nèi)部對象池中，維護(hù)一定數(shù)量的數(shù)據(jù)庫連接，并對外暴露數(shù)據(jù)庫連接的獲取和返回方法。
應(yīng)用程序和數(shù)據(jù)庫建立連接的過程：
1、?通過TCP協(xié)議的三次握手和數(shù)據(jù)庫服務(wù)器建立連接
2、?發(fā)送數(shù)據(jù)庫用戶賬號密碼，等待數(shù)據(jù)庫驗證用戶身份
3、?完成身份驗證后，系統(tǒng)可以提交SQL語句到數(shù)據(jù)庫執(zhí)行
4、?把連接關(guān)閉，TCP四次揮手告別。
數(shù)據(jù)庫連接池好處：
1、?資源重用 (連接復(fù)用)
2、?更快的系統(tǒng)響應(yīng)速度
3、?新的資源分配手段
4、?統(tǒng)一的連接管理，避免數(shù)據(jù)庫連接泄漏
27、列對比運算符是什么？
在SELECT語句的列比較中使用=，<>，<=，<，> =，>，<<，>>，<=>，AND，OR或LIKE運算符。
28、按照鎖的粒度分，數(shù)據(jù)庫鎖有哪些呢？鎖機制與InnoDB鎖算法
按鎖粒度分有：表鎖，頁鎖，行鎖
按鎖機制分有：樂觀鎖，悲觀鎖
29、LIKE聲明中的％和_是什么意思？
％對應(yīng)于0個或更多字符，_只是LIKE語句中的一個字符。
如何在Unix和MySQL時間戳之間進(jìn)行轉(zhuǎn)換？
UNIX_TIMESTAMP是從MySQL時間戳轉(zhuǎn)換為Unix時間戳的命令
FROM_UNIXTIME是從Unix時間戳轉(zhuǎn)換為MySQL時間戳的命令
30、如何定位及優(yōu)化SQL語句的性能問題？創(chuàng)建的索引有沒有被使用到?或者說怎么才可以知道這條語句運行很慢的原因？
對于低性能的SQL語句的定位，最重要也是最有效的方法就是使用執(zhí)行計劃，MySQL提供了explain命令來查看語句的執(zhí)行計劃。 我們知道，不管是哪種數(shù)據(jù)庫，或者是哪種數(shù)據(jù)庫引擎，在對一條SQL語句進(jìn)行執(zhí)行的過程中都會做很多相關(guān)的優(yōu)化，對于查詢語句，最重要的優(yōu)化方式就是使用索引。 而執(zhí)行計劃，就是顯示數(shù)據(jù)庫引擎對于SQL語句的執(zhí)行的詳細(xì)情況，其中包含了是否使用索引，使用什么索引，使用的索引的相關(guān)信息等。
執(zhí)行計劃包含的信息?id?有一組數(shù)字組成。表示一個查詢中各個子查詢的執(zhí)行順序;
1、?id相同執(zhí)行順序由上至下。
2、?id不同，id值越大優(yōu)先級越高，越先被執(zhí)行。
3、?id為null時表示一個結(jié)果集，不需要使用它查詢，常出現(xiàn)在包含union等查詢語句中。
select_type?每個子查詢的查詢類型，一些常見的查詢類型。
table?查詢的數(shù)據(jù)表，當(dāng)從衍生表中查數(shù)據(jù)時會顯示 x 表示對應(yīng)的執(zhí)行計劃id?partitions?表分區(qū)、表創(chuàng)建的時候可以指定通過那個列進(jìn)行表分區(qū)。 舉個例子：
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 掃描全表數(shù)據(jù)
2、?index 遍歷索引
3、?range 索引范圍查找
4、?index_subquery 在子查詢中使用 ref
5、?unique_subquery 在子查詢中使用 eq_ref
6、?ref_or_null 對Null進(jìn)行索引的優(yōu)化的 ref
7、?fulltext 使用全文索引
8、?ref 使用非唯一索引查找數(shù)據(jù)
9、?eq_ref 在join查詢中使用PRIMARY KEYorUNIQUE NOT NULL索引關(guān)聯(lián)。
10、?possible_keys?可能使用的索引，注意不一定會使用。查詢涉及到的字段上若存在索引，則該索引將被列出來。當(dāng)該列為 NULL時就要考慮當(dāng)前的SQL是否需要優(yōu)化了。
11、?key?顯示MySQL在查詢中實際使用的索引，若沒有使用索引，顯示為NULL。
12、?TIPS:查詢中若使用了覆蓋索引(覆蓋索引：索引的數(shù)據(jù)覆蓋了需要查詢的所有數(shù)據(jù))，則該索引僅出現(xiàn)在key列表中
13、?key_length?索引長度
14、?ref?表示上述表的連接匹配條件，即哪些列或常量被用于查找索引列上的值
15、?rows?返回估算的結(jié)果集數(shù)目，并不是一個準(zhǔn)確的值。
16、?extra?的信息非常豐富，常見的有：
17、?Using index 使用覆蓋索引
18、?Using where 使用了用where子句來過濾結(jié)果集
19、?Using filesort 使用文件排序，使用非索引列進(jìn)行排序時出現(xiàn)，非常消耗性能，盡量優(yōu)化。
20、?Using temporary 使用了臨時表 sql優(yōu)化的目標(biāo)可以參考阿里開發(fā)手冊
推薦
SQL性能優(yōu)化的目標(biāo)：至少要達(dá)到 range 級別，要求是ref級別，如果可以是consts最好
說明：
1、?consts 單表中最多只有一個匹配行（主鍵或者唯一索引），在優(yōu)化階段即可讀取到數(shù)據(jù)。
2、?ref 指的是使用普通的索引（normal index）。
3、?range 對索引進(jìn)行范圍檢索。
反例：
explain表的結(jié)果，type=index，索引物理文件全掃描，速度非常慢，這個index級別比較range還低，與全表掃描是小巫見大巫。
更多 MySQL面試題 80道
01、UNION與UNION ALL的區(qū)別？
02、CHAR和VARCHAR的區(qū)別？
03、Hash索引和B+樹所有有什么區(qū)別或者說優(yōu)劣呢?
04、索引的基本原理
05、簡單總結(jié)下
06、什么是死鎖？怎么解決？
07、LIKE聲明中的％和_是什么意思？
08、SQL 約束有哪幾種呢？
09、創(chuàng)建索引的三種方式
10、為什么官方建議使用自增長主鍵作為索引？
11、使用悲觀鎖
12、一個6億的表a，一個3億的表b，通過外間tid關(guān)聯(lián)，你如何最快的查詢出滿足條件的第50000到第50200中的這200條數(shù)據(jù)記錄。
13、覆蓋索引、回表等這些，了解過嗎？
14、索引能干什么?
15、為什么要盡量設(shè)定一個主鍵？
16、數(shù)據(jù)庫三大范式是什么
17、MySQL的binlog有有幾種錄入格式？分別有什么區(qū)別？
08、MySQL為什么這么設(shè)計
19、主鍵使用自增ID還是UUID，為什么？
20、索引使用場景
21、隔離級別與鎖的關(guān)系
22、MySQL事務(wù)得四大特性以及實現(xiàn)原理
23、鎖的優(yōu)化策略
24、varchar與char的區(qū)別
25、最左匹配原則？
26、創(chuàng)建索引的三種方式
27、日常工作中你是怎么優(yōu)化SQL的？
28、主從同步延遲的解決辦法
29、關(guān)心過業(yè)務(wù)系統(tǒng)里面的sql耗時嗎？統(tǒng)計過慢查詢嗎？對慢查詢都怎么優(yōu)化過？
30、MySQL的binlog有幾種錄入格式？分別有什么區(qū)別？
31、按照鎖的粒度分?jǐn)?shù)據(jù)庫鎖有哪些？鎖機制與InnoDB鎖算法
32、數(shù)據(jù)庫索引的原理，為什么要用 B+樹，為什么不用二叉樹？
33、MYSQL數(shù)據(jù)庫服務(wù)器性能分析的方法命令有哪些?
34、SQL語句的語法順序：
35、簡述在MySQL數(shù)據(jù)庫中MyISAM和InnoDB的區(qū)別
36、一個6億的表a，一個3億的表b，通過外間tid關(guān)聯(lián)，你如何最快的查詢出滿足條件的第50000到第50200中的這200條數(shù)據(jù)記錄。
37、MySQL的復(fù)制原理以及流程
38、讀寫分離常見方案？
39、drop、delete與truncate的區(qū)別
40、字段為什么要求定義為not null？
41、非聚簇索引一定會回表查詢嗎？
42、varchar(50)中50的涵義
43、完整性約束包括哪些？
44、談?wù)劻N關(guān)聯(lián)查詢，使用場景。
45、MVCC熟悉嗎，它的底層原理？
46、鎖的優(yōu)化策略
47、什么是聚簇索引？何時使用聚簇索引與非聚簇索引
48、500臺db，在最快時間之內(nèi)重啟。
49、你們數(shù)據(jù)庫是否支持emoji表情存儲，如果不支持，如何操作？
50、說一下大表查詢的優(yōu)化方案
51、數(shù)據(jù)庫自增主鍵可能遇到什么問題。
52、MySQL中InnoDB引擎的行鎖是怎么實現(xiàn)的？
53、MySQL有關(guān)權(quán)限的表都有哪幾個？
54、索引失效情況？ ==校驗SQL語句是否使用了索引方式為：
55、什么情況下設(shè)置了索引但無法使用
56、為什么要使用視圖？什么是視圖？
57、MySQL中InnoDB引擎的行鎖是怎么實現(xiàn)的？
58、怎么優(yōu)化SQL查詢語句嗎
59、如何刪除索引
60、說一下數(shù)據(jù)庫的三大范式
71、MySQL中有哪幾種鎖？
72、myisamchk是用來做什么的？
73、NULL是什么意思
74、讀寫分離有哪些解決方案？
75、數(shù)據(jù)庫為什么使用B+樹而不是B樹
76、Innodb的事務(wù)實現(xiàn)原理？
07、varchar(50)中50的涵義
78、一條SQL語句在MySQL中如何執(zhí)行的？
79、什么是死鎖？怎么解決？
80、如何在Unix和MySQL時間戳之間進(jìn)行轉(zhuǎn)換？
如果不背 MySQL面試題的答案，肯定面試會掛！
這套MySQL面試題大全，希望對大家有幫助哈~
博主已將以下這些面試題整理成了一個面試手冊，是PDF版的
總結(jié)
以上是生活随笔為你收集整理的110道 MySQL面试题及答案 （持续更新）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 小程序 mpvue input 文本控制
- 下一篇： 项目复审——Beta阶段