建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
本篇內(nèi)容介紹了“MySQL的高頻面試題有哪些”的有關(guān)知識(shí)，在實(shí)際案例的操作過(guò)程中，不少人都會(huì)遇到這樣的困境，接下來(lái)就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！
創(chuàng)新互聯(lián)-專(zhuān)業(yè)網(wǎng)站定制、快速模板網(wǎng)站建設(shè)、高性?xún)r(jià)比平邑網(wǎng)站開(kāi)發(fā)、企業(yè)建站全套包干低至880元,成熟完善的模板庫(kù),直接使用。一站式平邑網(wǎng)站制作公司更省心,省錢(qián),快速模板網(wǎng)站建設(shè)找我們，業(yè)務(wù)覆蓋平邑地區(qū)。費(fèi)用合理售后完善，十年實(shí)體公司更值得信賴(lài)。
1.什么是關(guān)系型數(shù)據(jù)庫(kù)?談?wù)勀銓?duì) MySQL 的認(rèn)識(shí)。
這是一道基礎(chǔ)題，考察面試者對(duì)數(shù)據(jù)庫(kù)的了解程度，一般可以簡(jiǎn)單講下自己的認(rèn)知，有條理即可。比如：
關(guān)系型數(shù)據(jù)庫(kù)是指采用了關(guān)系模型來(lái)組織數(shù)據(jù)的數(shù)據(jù)庫(kù)，其以行和列的形式存儲(chǔ)數(shù)據(jù)。關(guān)系型數(shù)據(jù)庫(kù)最大的特點(diǎn)是支持事務(wù)。常見(jiàn)的關(guān)系型數(shù)據(jù)庫(kù)有 MySQL、Oracle、SQLServer 等。MySQL 是當(dāng)下最流行的開(kāi)源數(shù)據(jù)庫(kù)。由于其體積小、速度快、總體擁有成本低，尤其是開(kāi)放源碼這一特點(diǎn)，使得很多公司都采用 MySQL 數(shù)據(jù)庫(kù)以降低成本，目前被廣泛地應(yīng)用在 Internet 上的中小型網(wǎng)站中，尤其適用于 OLTP 領(lǐng)域。
2.MySQL 常見(jiàn)的存儲(chǔ)引擎有哪些，有什么區(qū)別?
這個(gè)問(wèn)題也經(jīng)常被問(wèn)到，和『InnoDB 與 MyISAM 引擎的區(qū)別』問(wèn)題相似。
常見(jiàn)的幾種存儲(chǔ)引擎：
InnoDB: MySQL 默認(rèn)的存儲(chǔ)引擎，支持事務(wù)、MVCC、外鍵、行級(jí)鎖和自增列。
MyISAM: 支持全文索引、壓縮、空間函數(shù)、表級(jí)鎖，不支持事務(wù)，插入速度快。
Memory: 數(shù)據(jù)都在內(nèi)存中，數(shù)據(jù)的處理速度快，但是安全性不高。
ARCHIVE: 常用于歷史歸檔表，占用空間小，數(shù)據(jù)不能更新刪除。
InnoDB 與 MyISAM 引擎的幾點(diǎn)區(qū)別：
InnoDB 支持事務(wù)，MyISAM 不支持事務(wù)。
InnoDB 支持外鍵，而 MyISAM 不支持。
InnoDB 不支持全文索引，而 MyISAM 支持。
InnoDB 是聚簇索引，MyISAM 是非聚簇索引。
InnoDB 不保存表的具體行數(shù)，而 MyISAM 用一個(gè)變量保存了整個(gè)表的行數(shù)。
InnoDB 最小的鎖粒度是行鎖，MyISAM 最小的鎖粒度是表鎖。
存儲(chǔ)結(jié)構(gòu)不同，MyISAM 表分為 frm MYD MYI 三個(gè)，InnoDB 一般分為 frm ibd 兩個(gè)。
3.描述下 MySQL 基礎(chǔ)架構(gòu)。
這個(gè)問(wèn)題考察面試者對(duì) MySQL 架構(gòu)的了解，和『一條 select 語(yǔ)句執(zhí)行流程』問(wèn)題相似。
MySQL的邏輯架構(gòu)圖
MySQL的邏輯架構(gòu)主要分為3層：
鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)
第一層：對(duì)客戶(hù)端的連接處理、安全認(rèn)證、授權(quán)等，每個(gè)客戶(hù)端連接都會(huì)在服務(wù)端擁有一個(gè)線(xiàn)程，每個(gè)連接發(fā)起的查詢(xún)都會(huì)在對(duì)應(yīng)的單獨(dú)線(xiàn)程中執(zhí)行。
第二層：MySQL的核心服務(wù)功能層，包括查詢(xún)解析、分析、查詢(xún)緩存、內(nèi)置函數(shù)、存儲(chǔ)過(guò)程、觸發(fā)器、視圖等，select操作會(huì)先檢查是否命中查詢(xún)緩存，命中則直接返回緩存數(shù)據(jù)，否則解析查詢(xún)并創(chuàng)建對(duì)應(yīng)的解析樹(shù)。
第三層：存儲(chǔ)引擎，負(fù)責(zé)數(shù)據(jù)的存儲(chǔ)和提取，MySQL服務(wù)器通過(guò)API與存儲(chǔ)引擎通信，屏蔽了各種引擎之間的差異，常見(jiàn)的存儲(chǔ)引擎有：InnoDB、MyISAM。
一條 select 語(yǔ)句執(zhí)行流程：
客戶(hù)端通過(guò)連接器與 MySQL 服務(wù)器建立連接，并獲取了用戶(hù)的讀寫(xiě)權(quán)限，然后提交查詢(xún)語(yǔ)句。
首先 MySQL 會(huì)在查詢(xún)緩存中對(duì)提交的語(yǔ)句進(jìn)行查詢(xún)，如果命中且用戶(hù)對(duì)表有操作權(quán)限，會(huì)直接返回查詢(xún)緩存中查詢(xún)結(jié)果作為本次查詢(xún)的結(jié)果，查詢(xún)到此結(jié)束。
如果查詢(xún)緩存未命中，會(huì)來(lái)到分析器，分析器會(huì)解析語(yǔ)句并檢查其合法性。如果語(yǔ)句不符合 MySQL 的語(yǔ)法規(guī)范，執(zhí)行器會(huì)報(bào)錯(cuò)，查詢(xún)到此結(jié)束。
若語(yǔ)句合法，會(huì)來(lái)到優(yōu)化器，優(yōu)化器會(huì)為 SQL 語(yǔ)句選擇最優(yōu)的執(zhí)行計(jì)劃。
最后來(lái)到執(zhí)行器，如果用戶(hù)對(duì)表有操作權(quán)限，執(zhí)行器會(huì)調(diào)用存儲(chǔ)引擎提供的接口來(lái)執(zhí)行 SQL 語(yǔ)句，然后將查詢(xún)結(jié)果返回給客戶(hù)端，查詢(xún)到此結(jié)束。
4.說(shuō)說(shuō)常用的幾種字段類(lèi)型。
這個(gè)問(wèn)題考察面試者對(duì) MySQL 字段類(lèi)型的了解程度，可以延伸出很多小問(wèn)題，例如 char 與 varchar 的區(qū)別。
常用的字段類(lèi)型分類(lèi)：
數(shù)值型：
字符串類(lèi)型：
日期和時(shí)間類(lèi)型：
int(M)中的 M 代表最大顯示寬度，"最大顯示寬度"我們第一反應(yīng)是該字段的值最大能允許存放的值的寬度，以為我們建了int(1)，就不能存放數(shù)據(jù)10了, 其實(shí)不是這個(gè)意思，int(5)和int(10)可存儲(chǔ)的范圍一樣。
CHAR類(lèi)型是定長(zhǎng)的，MySQL總是根據(jù)定義的字符串長(zhǎng)度分配足夠的空間。當(dāng)保存CHAR值時(shí)，在它們的右邊填充空格以達(dá)到指定的長(zhǎng)度，當(dāng)檢索到CHAR值時(shí)，尾部的空格被刪除掉。VARCHAR類(lèi)型用于存儲(chǔ)可變長(zhǎng)字符串，存儲(chǔ)時(shí)，如果字符沒(méi)有達(dá)到定義的位數(shù)，也不會(huì)在后面補(bǔ)空格。char(M) 與 varchar(M)中的的 M 都表示保存的最大字符數(shù)，單個(gè)字母、數(shù)字、中文等都是占用一個(gè)字符。
5.講講索引的作用及結(jié)構(gòu)及使用規(guī)范。
關(guān)于索引，能有好多好多問(wèn)題，可能幾篇文章也寫(xiě)不明白。簡(jiǎn)單分享下這類(lèi)問(wèn)題的回答：
索引的目的在于提高查詢(xún)效率。可以類(lèi)比字典中的目錄，查找字典內(nèi)容時(shí)可以根據(jù)目錄查找到數(shù)據(jù)的存放位置，然后直接獲取即可。索引是表的目錄，在查找內(nèi)容之前可以先在目錄中查找索引位置，以此快速定位查詢(xún)數(shù)據(jù)。
InnoDB 引擎下，主要使用的是 B+Tree 索引，每個(gè)索引其實(shí)都是一顆B+樹(shù)，B+樹(shù)是為了磁盤(pán)及其他存儲(chǔ)輔助設(shè)備而設(shè)計(jì)的一種平衡查找樹(shù)(不是二叉樹(shù))，在B+樹(shù)中，所有的數(shù)據(jù)都在葉子節(jié)點(diǎn)，且每一個(gè)葉子節(jié)點(diǎn)都帶有指向下一個(gè)節(jié)點(diǎn)的指針，形成了一個(gè)有序的鏈表。
從物理存儲(chǔ)角度來(lái)看，InnoDB 索引可分為聚簇索引(clustered index)和二級(jí)索引(secondary index)或輔助索引。聚簇索引的葉子節(jié)點(diǎn)存的是整行數(shù)據(jù)，當(dāng)某條查詢(xún)使用的是聚簇索引時(shí)，只需要掃描聚簇索引一顆B+樹(shù)即可得到所需記錄，如果想通過(guò)二級(jí)索引來(lái)查找完整的記錄的話(huà)，需要通過(guò)回表操作，也就是在通過(guò)二級(jí)索引找到主鍵值之后再到聚簇索引中查找完整的記錄。
索引的優(yōu)點(diǎn)顯而易見(jiàn)是可以加速查詢(xún)，但創(chuàng)建索引也是有代價(jià)的。首先每建立一個(gè)索引都要為它建立一棵B+樹(shù)，會(huì)占用額外的存儲(chǔ)空間;其次當(dāng)對(duì)表中的數(shù)據(jù)進(jìn)行增加、刪除、修改時(shí)，索引也需要?jiǎng)討B(tài)的維護(hù)，降低了數(shù)據(jù)的維護(hù)速度。所以，索引的創(chuàng)建及使用時(shí)有原則的，一般只為用于搜索、排序、分組、連接的列創(chuàng)建索引，選擇性差的列盡量不創(chuàng)建索引。
6.講下 MySQL 事務(wù)的特性及隔離級(jí)別。
MySQL 事務(wù)相關(guān)問(wèn)題也經(jīng)常被問(wèn)到，一些原理性的東西還是需要深入去學(xué)習(xí)的。
ACID 四個(gè)特性：
A(Atomicity，原子性)：一個(gè)事務(wù)中的操作要么都成功，要么都失敗。
C(Consistency，一致性)：數(shù)據(jù)庫(kù)總是從一個(gè)一致性狀態(tài)轉(zhuǎn)換到另一個(gè)一致性狀態(tài)，若破壞約束，則不滿(mǎn)足一致性條件。
I(Isolation，隔離性)：一個(gè)事務(wù)的執(zhí)行不能其它事務(wù)干擾。即一個(gè)事務(wù)內(nèi)部的操作及使用的數(shù)據(jù)對(duì)其它并發(fā)事務(wù)是隔離的，并發(fā)執(zhí)行的各個(gè)事務(wù)之間不能互相干擾。
D(Durability，持久性)：事務(wù)在提交以后，它所做的修改就會(huì)被永久保存到數(shù)據(jù)庫(kù)。
事務(wù)隔離級(jí)別：
讀未提交(Read Uncommitted)：事務(wù)中的修改，即便沒(méi)有提交，對(duì)其他事務(wù)也都是可見(jiàn)的。
讀已提交(Read Committed):事務(wù)中的修改只有在提交之后，才會(huì)對(duì)其他事務(wù)可見(jiàn)。
可重復(fù)讀(Repeatable Read)：一個(gè)事務(wù)中多次查詢(xún)相同的記錄，結(jié)果總是一致的(默認(rèn)的隔離級(jí)別)。
可串行化(Serializable)：事務(wù)都是串行執(zhí)行的，讀會(huì)加讀鎖，寫(xiě)會(huì)加寫(xiě)鎖。
并發(fā)事務(wù)帶來(lái)的問(wèn)題：
臟讀(Dirty Reads)：事務(wù)A讀取了事務(wù)B未提交的數(shù)據(jù)，然后B回滾操作，那么A讀取到的數(shù)據(jù)是臟數(shù)據(jù)。
不可重復(fù)讀(Non-Repeatable Reads)：事務(wù) A 多次讀取同一數(shù)據(jù)，事務(wù)B在事務(wù)A多次讀取的過(guò)程中，對(duì)數(shù)據(jù)作了更新并提交，導(dǎo)致事務(wù)A多次讀取同一數(shù)據(jù)時(shí)，結(jié)果不一致。
幻讀(Phantom Reads)：幻讀與不可重復(fù)讀類(lèi)似。它發(fā)生在一個(gè)事務(wù)A讀取了幾行數(shù)據(jù)，接著另一個(gè)并發(fā)事務(wù)B插入了一些數(shù)據(jù)時(shí)。在隨后的查詢(xún)中，事務(wù)A就會(huì)發(fā)現(xiàn)多了一些原本不存在的記錄，就好像發(fā)生了幻覺(jué)一樣，所以稱(chēng)為幻讀。
“MySQL的高頻面試題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識(shí)可以關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！
網(wǎng)站欄目：MySQL的高頻面試題有哪些
URL地址：http://www.ef60e0e.cn/article/iipjjs.html
