MySQL高頻面試題都是怎么樣的

本篇文章給大家分享的是有關(guān)MySQL高頻面試題都是怎么樣的，小編覺(jué)得挺實(shí)用的，因此分享給大家學(xué)習(xí)，希望大家閱讀完這篇文章后可以有所收獲，話不多說(shuō)，跟著小編一起來(lái)看看吧。

唯一索引比普通索引快嗎, 為什么？

唯一索引不一定比普通索引快, 還可能慢。

1. 查詢(xún)時(shí), 在未使用limit 1的情況下, 在匹配到一條數(shù)據(jù)后, 唯一索引即返回, 普通索引會(huì)繼續(xù)匹配下一條數(shù)據(jù), 發(fā)現(xiàn)不匹配后返回. 如此看來(lái)唯一索引少了一次匹配, 但實(shí)際上這個(gè)消耗微乎其微.

2. 更新時(shí), 這個(gè)情況就比較復(fù)雜了. 普通索引將記錄放到change buffer中語(yǔ)句就執(zhí)行完畢了. 而對(duì)唯一索引而言, 它必須要校驗(yàn)唯一性, 因此, 必須將數(shù)據(jù)頁(yè)讀入內(nèi)存確定沒(méi)有沖突, 然后才能繼續(xù)操作. 對(duì)于寫(xiě)多讀少的情況, 普通索引利用change buffer有效減少了對(duì)磁盤(pán)的訪問(wèn)次數(shù), 因此普通索引性能要高于唯一索引.

3. 加q群：478052716 免費(fèi)領(lǐng)取（Java架構(gòu)資料，視頻資料，BATJ面試資料）

MySQL由哪些部分組成, 分別用來(lái)做什么

1. Server

2. 連接器: 管理連接, 權(quán)限驗(yàn)證.

3. 分析器: 詞法分析, 語(yǔ)法分析.

4. 優(yōu)化器: 執(zhí)行計(jì)劃生成, 索引的選擇.

5. 執(zhí)行器: 操作存儲(chǔ)引擎, 返回執(zhí)行結(jié)果.

6. 存儲(chǔ)引擎: 存儲(chǔ)數(shù)據(jù), 提供讀寫(xiě)接口.

7. 加q群：478052716 免費(fèi)領(lǐng)?。↗ava架構(gòu)資料，視頻資料，BATJ面試資料）

MySQL查詢(xún)緩存有什么弊端, 應(yīng)該什么情況下使用, 8.0版本對(duì)查詢(xún)緩存有什么變更.

• 查詢(xún)緩存可能會(huì)失效非常頻繁, 對(duì)于一個(gè)表, 只要有更新, 該表的全部查詢(xún)緩存都會(huì)被清空. 因此對(duì)于頻繁更新的表來(lái)說(shuō), 查詢(xún)緩存不一定能起到正面效果.

• 對(duì)于讀遠(yuǎn)多于寫(xiě)的表可以考慮使用查詢(xún)緩存.

• 8.0版本的查詢(xún)緩存功能被刪了 (￣.￣).

MyISAM和InnoDB的區(qū)別有哪些

• InnoDB支持事務(wù), MyISAM不支持.

• InnoDB支持行級(jí)鎖, MyISAM支持表級(jí)鎖.

• InnoDB支持多版本并發(fā)控制(MVVC), MyISAM不支持.

• InnoDB支持外鍵, MyISAM不支持.

• MyISAM支持全文索引, InnoDB不支持(但可以使用Sphinx插件)

MySQL怎么恢復(fù)半個(gè)月前的數(shù)據(jù)

通過(guò)整庫(kù)備份+binlog進(jìn)行恢復(fù). 前提是要有定期整庫(kù)備份且保存了binlog日志.

MySQL事務(wù)的隔離級(jí)別, 分別有什么特點(diǎn)

1. 讀未提交(RU): 一個(gè)事務(wù)還沒(méi)提交時(shí), 它做的變更就能被別的事務(wù)看到.

2. 讀提交(RC): 一個(gè)事務(wù)提交之后, 它做的變更才會(huì)被其他事務(wù)看到.

3. 可重復(fù)讀(RR): 一個(gè)事務(wù)執(zhí)行過(guò)程中看到的數(shù)據(jù), 總是跟這個(gè)事務(wù)在啟動(dòng)時(shí)看到的數(shù)據(jù)是一致的. 當(dāng)然在可重復(fù)讀隔離級(jí)別下, 未提交變更對(duì)其他事務(wù)也是不可見(jiàn)的.

4. 串行化(S): 對(duì)于同一行記錄, 讀寫(xiě)都會(huì)加鎖. 當(dāng)出現(xiàn)讀寫(xiě)鎖沖突的時(shí)候, 后訪問(wèn)的事務(wù)必須等前一個(gè)事務(wù)執(zhí)行完成才能繼續(xù)執(zhí)行.

做過(guò)哪些MySQL索引相關(guān)優(yōu)化

• 盡量使用主鍵查詢(xún): 聚簇索引上存儲(chǔ)了全部數(shù)據(jù), 相比普通索引查詢(xún), 減少了回表的消耗.

• MySQL5.6之后引入了索引下推優(yōu)化, 通過(guò)適當(dāng)?shù)氖褂寐?lián)合索引, 減少回表判斷的消耗.

• 若頻繁查詢(xún)某一列數(shù)據(jù), 可以考慮利用覆蓋索引避免回表.

• 聯(lián)合索引將高頻字段放在最左邊.

簡(jiǎn)要說(shuō)一下數(shù)據(jù)庫(kù)范式

• 第一范式: 屬性不可再分.

• 第二范式: 在一范式的基礎(chǔ)上, 要求數(shù)據(jù)庫(kù)表中的每個(gè)實(shí)例或行必須可以被惟一地區(qū)分. 通常需要為表加上一個(gè)列, 以存儲(chǔ)各個(gè)實(shí)例的惟一標(biāo)識(shí). 這個(gè)惟一屬性列被稱(chēng)為主關(guān)鍵字或主鍵.

• 第三范式: 在二范式的基礎(chǔ)上, 要求一個(gè)數(shù)據(jù)庫(kù)表中不包含已在其它表中已包含的非主關(guān)鍵字信息. 所以第三范式具有如下特征：1). 每一列只有一個(gè)值. 2). 每一行都能區(qū)分. 3). 每一個(gè)表都不包含其他表已經(jīng)包含的非主關(guān)鍵字信息.

一千萬(wàn)條數(shù)據(jù)的表, 如何分頁(yè)查詢(xún)

數(shù)據(jù)量過(guò)大的情況下, limit offset分頁(yè)會(huì)由于掃描數(shù)據(jù)太多而越往后查詢(xún)?cè)铰? 可以配合當(dāng)前頁(yè)最后一條ID進(jìn)行查詢(xún), SELECT * FROM T WHERE id > #{ID} LIMIT #{LIMIT}. 當(dāng)然, 這種情況下ID必須是有序的, 這也是有序ID的好處之一.

訂單表數(shù)據(jù)量越來(lái)越大導(dǎo)致查詢(xún)緩慢, 如何處理

分庫(kù)分表. 由于歷史訂單使用率并不高, 高頻的可能只是近期訂單, 因此, 將訂單表按照時(shí)間進(jìn)行拆分, 根據(jù)數(shù)據(jù)量的大小考慮按月分表或按年分表. 訂單ID最好包含時(shí)間(如根據(jù)雪花算法生成), 此時(shí)既能根據(jù)訂單ID直接獲取到訂單記錄, 也能按照時(shí)間進(jìn)行查詢(xún)。

以上就是MySQL高頻面試題都是怎么樣的，小編相信有部分知識(shí)點(diǎn)可能是我們?nèi)粘９ぷ鲿?huì)見(jiàn)到或用到的。希望你能通過(guò)這篇文章學(xué)到更多知識(shí)。更多詳情敬請(qǐng)關(guān)注億速云行業(yè)資訊頻道。