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阶段