MySQL在面試中經常被問到，本文總結了面試中的經典問題。

1. 數據庫三大范式是什么？

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

在設計數據庫結構的時候，要盡量遵守三范式，如果不遵守，必須有足夠的理由。

比如性能。事實上我們經常會為了性能而妥協數據庫的設計。

2. mysql有關權限的表都有哪幾個？

MySQL服務器通過權限表來控制用戶對數據庫的訪問，權限表存放在mysql數據庫里，由mysql_install_db腳本初始化。

這些權限表分別user，db，table_priv，columns_priv和host。

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

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

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

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

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

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

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

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

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

主要為以上操作 即對數據進行操作的，對應上面所說的查詢操作 DQL與DML共同構建了多數初級程序員常用的增刪改查操作。

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

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

主要為以上操作 即對數據庫安全性完整性等有操作的，可以簡單的理解為權限控制等。

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

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

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

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

死鎖是指兩個或多個事務在同一資源上相互占用，并請求鎖定對方的資源，從而導致惡性循環的現象。

常見的解決死鎖的方法：

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

7. 什么是臟讀？幻讀？不可重復讀？

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

8. 視圖有哪些特點？

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

• 視圖是由基本表(實表)產生的表(虛表)。視圖的建立和刪除不影響基本表。
• 對視圖內容的更新(添加，刪除和修改)直接影響基本表。
• 當視圖來自多個基本表時，不允許添加和刪除數據。
• 視圖的操作包括創建視圖，查看視圖，刪除視圖和修改視圖。

9. SQL的生命周期？

• 應用服務器與數據庫服務器建立一個連接
• 數據庫進程拿到請求sql
• 解析并生成執行計劃，執行
• 讀取數據到內存并進行邏輯處理
• 通過步驟一的連接，發送結果到客戶端
• 關掉連接，釋放資源

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

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

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

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

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

11. MySQL數據庫cpu飆升到100%的話怎么處理？

當 cpu 飆升到 100%時，先用操作系統命令 top 命令觀察是不是 mysqld 占用導致的。

如果不是，找出占用高的進程，并進行相關處理。

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

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

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

12. MySQL主從復制解決了哪些問題？

主從復制的作用是：

主數據庫出現問題，可以切換到從數據庫。可以進行數據庫層面的讀寫分離。可以在從數據庫上進行日常備份。

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

13. 什么是MySQL的GTID？

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

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

GTID實際上是由UUID+TID組成的。其中UUID是一個MySQL實例的唯一標識。

GTID代表了該實例上已經提交的事務數量，并且隨著事務提交單調遞增。

GTID有如下幾點作用：

• 根據GTID可以知道事務最初是在哪個實例上提交的。
• GTID的存在方便了Replication的Failover。因為不用像傳統模式復制那樣去找master_log_file和master_log_pos。
• 基于GTID搭建主從復制更加簡單， 確保每個事務只會被執行一次。

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

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

備份工具差異對比：

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

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

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

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

15. MySQL備份計劃如何制定？

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

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

一般是選擇一周一個全備，其余每天進行增量備份，備份時間為業務低峰期。