MySQL在面試中經(jīng)常被問到，本文總結(jié)了面試中的經(jīng)典問題。

創(chuàng)新互聯(lián)建站是一家以重慶網(wǎng)站建設(shè)公司、網(wǎng)頁設(shè)計(jì)、品牌設(shè)計(jì)、軟件運(yùn)維、成都網(wǎng)站營銷、小程序App開發(fā)等移動開發(fā)為一體互聯(lián)網(wǎng)公司。已累計(jì)為成都衛(wèi)生間隔斷等眾行業(yè)中小客戶提供優(yōu)質(zhì)的互聯(lián)網(wǎng)建站和軟件開發(fā)服務(wù)。

1. 數(shù)據(jù)庫三大范式是什么？

• 第一范式：每個列都不可以再拆分。
• 第二范式：在第一范式的基礎(chǔ)上，非主鍵列完全依賴于主鍵，而不能是依賴于主鍵的一部分。
• 第三范式：在第二范式的基礎(chǔ)上，非主鍵列只依賴于主鍵，不依賴于其他非主鍵。

在設(shè)計(jì)數(shù)據(jù)庫結(jié)構(gòu)的時候，要盡量遵守三范式，如果不遵守，必須有足夠的理由。

比如性能。事實(shí)上我們經(jīng)常會為了性能而妥協(xié)數(shù)據(jù)庫的設(shè)計(jì)。

2. mysql有關(guān)權(quán)限的表都有哪幾個？

MySQL服務(wù)器通過權(quán)限表來控制用戶對數(shù)據(jù)庫的訪問，權(quán)限表存放在mysql數(shù)據(jù)庫里，由mysql_install_db腳本初始化。

這些權(quán)限表分別user，db，table_priv，columns_priv和host。

• user權(quán)限表：記錄允許連接到服務(wù)器的用戶帳號信息，里面的權(quán)限是全局級的。
• db權(quán)限表：記錄各個帳號在各個數(shù)據(jù)庫上的操作權(quán)限。
• table_priv權(quán)限表：記錄數(shù)據(jù)表級的操作權(quán)限。
• columns_priv權(quán)限表：記錄數(shù)據(jù)列級的操作權(quán)限。
• host權(quán)限表：配合db權(quán)限表對給定主機(jī)上數(shù)據(jù)庫級操作權(quán)限作更細(xì)致的控制。這個權(quán)限表不受GRANT和REVOKE語句的影響。

3. 事務(wù)的四大特性(ACID)介紹一下？

• 原子性：事務(wù)是最小的執(zhí)行單位，不允許分割。事務(wù)的原子性確保動作要么全部完成，要么完全不起作用；
• 一致性：執(zhí)行事務(wù)前后，數(shù)據(jù)保持一致，多個事務(wù)對同一個數(shù)據(jù)讀取的結(jié)果是相同的；
• 隔離性：并發(fā)訪問數(shù)據(jù)庫時，一個用戶的事務(wù)不被其他事務(wù)所干擾，各并發(fā)事務(wù)之間數(shù)據(jù)庫是獨(dú)立的；
• 持久性：一個事務(wù)被提交之后。它對數(shù)據(jù)庫中數(shù)據(jù)的改變是持久的， 即使數(shù)據(jù)庫發(fā)生故障也不應(yīng)該對其有任何影響。

4. SQL語句主要分為哪幾類？

(1) 數(shù)據(jù)定義語言DDL(Data Ddefinition Language)CREATE，DROP，ALTER

主要為以上操作 即對邏輯結(jié)構(gòu)等有操作的，其中包括表結(jié)構(gòu)，視圖和索引。

(2) 數(shù)據(jù)查詢語言DQL(Data Query Language)SELECT

這個較為好理解 即查詢操作，以select關(guān)鍵字。各種簡單查詢，連接查詢等 都屬于DQL。

(3) 數(shù)據(jù)操縱語言DML(Data Manipulation Language)INSERT，UPDATE，DELETE

主要為以上操作 即對數(shù)據(jù)進(jìn)行操作的，對應(yīng)上面所說的查詢操作 DQL與DML共同構(gòu)建了多數(shù)初級程序員常用的增刪改查操作。

而查詢是較為特殊的一種 被劃分到DQL中。

(4) 數(shù)據(jù)控制功能DCL(Data Control Language)GRANT，REVOKE，COMMIT，ROLLBACK

主要為以上操作 即對數(shù)據(jù)庫安全性完整性等有操作的，可以簡單的理解為權(quán)限控制等。

5. MySQL分庫分表的目的是？

分庫分表就是為了 解決由于數(shù)據(jù)量過大而導(dǎo)致數(shù)據(jù)庫性能降低的問題， 將原來獨(dú)立的數(shù)據(jù)庫拆分成若干數(shù)據(jù)庫組成，將數(shù)據(jù)大表拆分成若干數(shù)據(jù)表組成， 使得單一數(shù)據(jù)庫、單一數(shù)據(jù)表的數(shù)據(jù)量變小，從而達(dá)到提升數(shù)據(jù)庫性能的目的。

分庫分表常用的中間件如下：

6. 什么是死鎖？怎么解決？

死鎖是指兩個或多個事務(wù)在同一資源上相互占用，并請求鎖定對方的資源，從而導(dǎo)致惡性循環(huán)的現(xiàn)象。

常見的解決死鎖的方法：

• 如果不同程序會并發(fā)存取多個表， 盡量約定以相同的順序訪問表，可以大大降低死鎖機(jī)會；
• 在同一個事務(wù)中，盡可能做到一次鎖定所需要的所有資源，減少死鎖產(chǎn)生概率；
• 對于非常容易產(chǎn)生死鎖的業(yè)務(wù)部分，可以嘗試使用升級鎖定顆粒度，通過表級鎖定來減少死鎖產(chǎn)生的概率；
• 如果業(yè)務(wù)處理不好可以用分布式事務(wù)鎖或者使用樂觀鎖。

7. 什么是臟讀？幻讀？不可重復(fù)讀？

• 臟讀(Drity Read)：某個事務(wù)已更新一份數(shù)據(jù)，另一個事務(wù)在此時讀取了同一份數(shù)據(jù)， 由于某些原因，前一個RollBack了操作，則后一個事務(wù)所讀取的數(shù)據(jù)就會是不正確的。
• 不可重復(fù)讀(Non-repeatable read)：在一個事務(wù)的兩次查詢之中數(shù)據(jù)不一致， 這可能是兩次查詢過程中間插入了一個事務(wù)更新的原有的數(shù)據(jù)。
• 幻讀(Phantom Read)：在一個事務(wù)的兩次查詢中數(shù)據(jù)筆數(shù)不一致， 例如有一個事務(wù)查詢了幾列(Row)數(shù)據(jù)， 而另一個事務(wù)卻在此時插入了新的幾列數(shù)據(jù)，先前的事務(wù)在接下來的查詢中， 就會發(fā)現(xiàn)有幾列數(shù)據(jù)是它先前所沒有的。

8. 視圖有哪些特點(diǎn)？

視圖的特點(diǎn)如下: 視圖的列可以來自不同的表，是表的抽象和在邏輯意義上建立的新關(guān)系。

• 視圖是由基本表(實(shí)表)產(chǎn)生的表(虛表)。視圖的建立和刪除不影響基本表。
• 對視圖內(nèi)容的更新(添加，刪除和修改)直接影響基本表。
• 當(dāng)視圖來自多個基本表時，不允許添加和刪除數(shù)據(jù)。
• 視圖的操作包括創(chuàng)建視圖，查看視圖，刪除視圖和修改視圖。

9. SQL的生命周期？

• 應(yīng)用服務(wù)器與數(shù)據(jù)庫服務(wù)器建立一個連接
• 數(shù)據(jù)庫進(jìn)程拿到請求sql
• 解析并生成執(zhí)行計(jì)劃，執(zhí)行
• 讀取數(shù)據(jù)到內(nèi)存并進(jìn)行邏輯處理
• 通過步驟一的連接，發(fā)送結(jié)果到客戶端
• 關(guān)掉連接，釋放資源

10. 主鍵使用自增ID還是UUID？

推薦使用自增ID，不要使用UUID。

因?yàn)樵贗nnoDB存儲引擎中，主鍵索引是作為聚簇索引存在的，也就是說， 主鍵索引的B+樹葉子節(jié)點(diǎn)上存儲了主鍵索引以及全部的數(shù)據(jù)(按照順序)， 如果主鍵索引是自增ID，那么只需要不斷向后排列即可，如果是UUID， 由于到來的ID與原來的大小不確定，會造成非常多的數(shù)據(jù)插入，數(shù)據(jù)移動，然后導(dǎo)致產(chǎn)生很多的內(nèi)存碎片，進(jìn)而造成插入性能的下降。

總之，在數(shù)據(jù)量大一些的情況下，用自增主鍵性能會好一些。

關(guān)于主鍵是聚簇索引，如果沒有主鍵，InnoDB會選擇一個唯一鍵來作為聚簇索引，如果沒有唯一鍵，會生成一個隱式的主鍵。

11. MySQL數(shù)據(jù)庫cpu飆升到100%的話怎么處理？

當(dāng) cpu 飆升到 100%時，先用操作系統(tǒng)命令 top 命令觀察是不是 mysqld 占用導(dǎo)致的。

如果不是，找出占用高的進(jìn)程，并進(jìn)行相關(guān)處理。

如果是 mysqld 造成的， show processlist，看看里面跑的 session 情況，是不是有消耗資源的 sql 在運(yùn)行。找出消耗高的 sql，看看執(zhí)行計(jì)劃是否準(zhǔn)確，index 是否缺失，或者實(shí)在是數(shù)據(jù)量太大造成。

一般來說，肯定要 kill 掉這些線程(同時觀察 cpu 使用率是否下降)， 等進(jìn)行相應(yīng)的調(diào)整(比如說加索引、改 sql、改內(nèi)存參數(shù))之后，再重新跑這些 SQL。

也有可能是每個 sql 消耗資源并不多，但是突然之間，有大量的 session 連進(jìn)來導(dǎo)致 cpu 飆升， 這種情況就需要跟應(yīng)用一起來分析為何連接數(shù)會激增， 再做出相應(yīng)的調(diào)整，比如說限制連接數(shù)等。

12. MySQL主從復(fù)制解決了哪些問題？

主從復(fù)制的作用是：

主數(shù)據(jù)庫出現(xiàn)問題，可以切換到從數(shù)據(jù)庫?？梢赃M(jìn)行數(shù)據(jù)庫層面的讀寫分離。可以在從數(shù)據(jù)庫上進(jìn)行日常備份。

• 數(shù)據(jù)分布：隨意開始或停止復(fù)制，并在不同地理位置分布數(shù)據(jù)備份
• 負(fù)載均衡：降低單個服務(wù)器的壓力
• 高可用和故障切換：幫助應(yīng)用程序避免單點(diǎn)失敗
• 升級測試：可以用更高版本的MySQL作為從庫

13. 什么是MySQL的GTID？

TID(Global Transaction ID，全局事務(wù)ID)是全局事務(wù)標(biāo)識符， 是一個已提交事務(wù)的編號，并且是一個全局唯一的編號。

GTID是從MySQL 5.6版本開始在主從復(fù)制方面推出的重量級特性。

GTID實(shí)際上是由UUID+TID組成的。其中UUID是一個MySQL實(shí)例的唯一標(biāo)識。

GTID代表了該實(shí)例上已經(jīng)提交的事務(wù)數(shù)量，并且隨著事務(wù)提交單調(diào)遞增。

GTID有如下幾點(diǎn)作用：

• 根據(jù)GTID可以知道事務(wù)最初是在哪個實(shí)例上提交的。
• GTID的存在方便了Replication的Failover。因?yàn)椴挥孟駛鹘y(tǒng)模式復(fù)制那樣去找master_log_file和master_log_pos。
• 基于GTID搭建主從復(fù)制更加簡單， 確保每個事務(wù)只會被執(zhí)行一次。

14. MySQL常用的備份工具有哪些？

• 常用備份工具mysql復(fù)制
• 邏輯備份(mysqldump，mydumper)
• 物理備份(copy,xtrabackup)

備份工具差異對比：

(1) mysql復(fù)制相對于其他的備份來說，得到的備份數(shù)據(jù)比較實(shí)時。

• 邏輯備份：分表比較容易。mysqldump備份數(shù)據(jù)時是將所有sql語句整合在同一個文件中；mydumper備份數(shù)據(jù)時是將SQL語句按照表拆分成單個的sql文件， 每個sql文件對應(yīng)一個完整的表。
• 物理備份：拷貝即可用，速度快。

(2) copy：直接拷貝文件到數(shù)據(jù)目錄下，可能引起表損壞或者數(shù)據(jù)不一致。

(3) xtrabackup對于innodb表是不需要鎖表的，對于myisam表仍然需要鎖表。

15. MySQL備份計(jì)劃如何制定？

視庫的大小來定，一般來說 100G 內(nèi)的庫，可以考慮使用 mysqldump 來做， 因?yàn)?mysqldump更加輕巧靈活，備份時間選在業(yè)務(wù)低峰期， 可以每天進(jìn)行都進(jìn)行全量備份(mysqldump 備份出來的文件比較小，壓縮之后更小)。

100G 以上的庫，可以考慮用 xtranbackup 來做，備份速度明顯要比 mysqldump 要快。

一般是選擇一周一個全備，其余每天進(jìn)行增量備份，備份時間為業(yè)務(wù)低峰期。

分享文章：MySQL奪命15問，你能堅(jiān)持到第幾問？
當(dāng)前地址：http://uogjgqi.cn/article/dpsdcep.html