MySQL數據庫常見面試題

 

 

什麼是存儲過程？有哪些優缺點？

存儲過程簡單來講就是爲了之後使用而保存的一條或多條預編譯SQL語句，這些語句塊像一個方法同樣執行一些功能。

優勢：

1. 相似於封裝，簡化操做；
2. 不用反覆創建一系列處理步驟，保證了數據的完整性；
3. 經過存儲過程可以使沒有權限的用戶在控制之下間接地存取數據庫，從而確保數據的安全。
4. 簡化對變更的管理，安全；
5. 存儲過程是一個編譯過的代碼塊，速度快，性能高；

缺點：

1. SQL自己是一種結構化查詢語言，但不是OO的，本質上仍是過程化的，面對複雜的業務邏輯，過程化的處理會很吃力；
2. 存儲過程的編寫比基本SQL語句複雜，須要較高的技能
3. 可能沒有建立存儲過程的權限

---

索引是什麼？有什麼做用？以及優缺點？使用索引查詢必定能提升查詢性能嗎？

索引是存儲引擎用於快速找到記錄的一種數據結構,索引相似一本書的目錄,咱們根據目錄能夠快速的查找到咱們感興趣的內容。索引就是存儲引擎的目錄,若是沒有索引存儲引擎必須遍歷整個數據庫表來查詢符合條件的記錄。通常來講，索引的創建和優化應該是提高查詢性能最有效的手段。

優勢：

（1）經過建立惟一性索引，能夠保證數據庫表中每一行數據的惟一性。
（2）能夠大大加快 數據的檢索速度，這也是建立索引的最主要的緣由。
（3）能夠加速表和表之間的鏈接，特別是在實現數據的參考完整性方面特別有意義。
（4）在使用分組和排序 子句進行數據檢索時，一樣能夠顯著減小查詢中分組和排序的時間。
（5）經過使用索引，能夠在查詢的過程當中，使用優化隱藏器，提升系統的性能。

缺點：

（1）建立索引和維護索引要耗費時間，這種時間隨着數據 量的增長而增長。
（2）索引須要佔物理空間，除了數據表佔數據空間以外，每個索引還要佔必定的物理空間，若是要創建聚簇索引，那麼須要的空間就會更大。
（3）當對錶中的數據進行增長、刪除和修改的時候，索引也要動態的維護，這樣就下降了數據的維護速度。

既然索引能夠加快查詢速度，那麼是否是隻要是查詢語句須要，就建上索引？答案是否認的。由於索引雖然加快了查詢速度，但索引也是有代價的：索引文件自己要消耗存儲空間，同時索引會加劇插入、刪除和修改記錄時的負擔，另外，MySQL在運行時也要消耗資源維護索引，所以索引並非越多越好。通常兩種狀況下不建議建索引。

第一種狀況是表記錄比較少，例如一兩千條甚至只有幾百條記錄的表，不必建索引，讓查詢作全表掃描就行了。至於多少條記錄纔算多，這個我的有我的的見解，我我的的經驗是以2000做爲分界線，記錄數不超過 2000能夠考慮不建索引，超過2000條能夠酌情考慮索引。

另外一種不建議建索引的狀況是索引的選擇性較低。所謂索引的選擇性（Selectivity），是指不重複的索引值（也叫基數，Cardinality）與表記錄數（#T）的比值：

Index Selectivity = Cardinality / #T

顯然選擇性的取值範圍爲(0, 1]，選擇性越高的索引價值越大。

---

什麼是事務？

事務（Transaction）是併發控制的基本單位。所謂的事務，它是一個操做序列，這些操做要麼都執行，要麼都不執行，它是一個不可分割的工做單位。事務是數據庫維護數據一致性的單位，在每一個事務結束時，都能保持數據一致性。知足ACID特性。

---

數據庫的樂觀鎖和悲觀鎖？

數據庫管理系統（DBMS）中的併發控制的任務是確保在多個事務同時存取數據庫中同一數據時不破壞事務的隔離性和統一性以及數據庫的統一性。

樂觀併發控制(樂觀鎖)和悲觀併發控制（悲觀鎖）是併發控制主要採用的技術手段。

• 悲觀鎖：假定會發生併發衝突，屏蔽一切可能違反數據完整性的操做
• 樂觀鎖：假設不會發生併發衝突，只在提交操做時檢查是否違反數據完整性。

悲觀鎖：

在對任意記錄進行修改前，先嚐試爲該記錄加上排他鎖（exclusive locking）。

若是加鎖失敗，說明該記錄正在被修改，那麼當前查詢可能要等待或者拋出異常。 具體響應方式由開發者根據實際須要決定。

若是成功加鎖，那麼就能夠對記錄作修改，事務完成後就會解鎖了。

其間若是有其餘對該記錄作修改或加排他鎖的操做，都會等待咱們解鎖或直接拋出異常。

優勢與不足

悲觀併發控制其實是「先取鎖再訪問」的保守策略，爲數據處理的安全提供了保證。可是在效率方面，處理加鎖的機制會讓數據庫產生額外的開銷，還有增長產生死鎖的機會；另外，在只讀型事務處理中因爲不會產生衝突，也不必使用鎖，這樣作只能增長系統負載；還有會下降了並行性，一個事務若是鎖定了某行數據，其餘事務就必須等待該事務處理完才能夠處理那行數

 

樂觀鎖:

在關係數據庫管理系統裏，樂觀併發控制是一種併發控制的方法。它假設多用戶併發的事務在處理時不會彼此互相影響，各事務可以在不產生鎖的狀況下處理各自影響的那部分數據。在提交數據更新以前，每一個事務會先檢查在該事務讀取數據後，有沒有其餘事務又修改了該數據。若是其餘事務有更新的話，正在提交的事務會進行回滾。

相對於悲觀鎖，在對數據庫進行處理的時候，樂觀鎖並不會使用數據庫提供的鎖機制。通常的實現樂觀鎖的方式就是記錄數據版本。數據版本,爲數據增長的一個版本標識。當讀取數據時，將版本標識的值一同讀出，數據每更新一次，同時對版本標識進行更新。當咱們提交更新的時候，判斷數據庫表對應記錄的當前版本信息與第一次取出來的版本標識進行比對，若是數據庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，不然認爲是過時數據。實現數據版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

優勢與不足

樂觀併發控制相信事務之間的數據競爭(data race)的機率是比較小的，所以儘量直接作下去，直到提交的時候纔去鎖定，因此不會產生任何鎖和死鎖。但若是直接簡單這麼作，仍是有可能會遇到不可預期的結果，例如兩個事務都讀取了數據庫的某一行，通過修改之後寫回數據庫，這時就遇到了問題。

---

簡單說一下DROP, DELETE, TRUNCATE的區別？

• DELETE：執行刪除的過程是每次從表中刪除一行，而且同時將該行的刪除操做做爲事務記錄在日誌中保存以便進行進行回滾操做。DELETE只是刪除表中的數據，並不刪除表自己； 能夠回滾撤銷。
• TRUNCATE ：TRUNCATE與DELETE語句執行相同的功能，可是在刪除的過程當中不會激活與表有關的刪除觸發器，速度更快，實際是刪除原來的表並從新建立一個新的表，不是逐行刪除；刪除全部的數據時並不把單獨的刪除操做記錄記入日誌保存，刪除行是不能恢復的。TRUNCATE只是刪除表中的數據，並不刪除表自己；不能夠回滾撤銷。
• DROP：drop語句刪除表結構及全部數據，並將表所佔用的空間所有釋放。drop是DDL，會隱式提交，因此，不能回滾，不會觸發觸發器。drop語句將刪除表的結構所依賴的約束，觸發器，索引，依賴於該表的存儲過程/函數將保留,可是變爲invalid狀態。不能夠回滾撤銷。

速度：DROP > TRUNCATE > DELETE

只能對table使用TRUNCATE；        

能夠對table和view使用DELETE;

---

DROP, DELETE, TRUNCATE 分別在什麼場景下使用？

若是想徹底刪除數據表，使用DROP；

若是想刪除表中的全部數據，可是保留表結構，使用TRUNCATE TABLE；

其餘使用DELETE，可是要帶上where語句

---

超鍵，主鍵，外鍵，候選鍵分別是什麼？

假設有以下兩個表：

學生（學號，姓名，性別，身份證號，教師編號）       教師（教師編號，姓名，工資）

• 主鍵(primary key)：對數據庫表中的每一行數據進行惟一標識的字段。
• 外鍵(foreign key)：是表中的一列，其值必須在另外一個表的主鍵中。外鍵主要是用來描述兩個表的關係。
• 超鍵(super key)：在關係中能惟一標識元組的屬性集稱爲關係模式的超鍵。 好比一張學生信息表，學生表中含有學號或者身份證號的任意組合都爲此表的超鍵。如：（學號）、（學號，姓名）、（身份證號，性別）等。
• 候選鍵(candidate key)：不含有多餘屬性的超鍵稱爲候選鍵，也稱爲最小超鍵 候選鍵屬於超鍵，它是最小的超鍵，就是說若是再去掉候選鍵中的任何一個屬性它就再也不是超鍵了。學生表中的候選鍵爲：（學號）、（身份證號）。

---

什麼是視圖？視圖的優缺點？以及視圖的使用場景？

視圖是基於 SQL 語句的結果集的可視化的虛擬表。與包含數據的表不一樣，視圖只包含使用時動態檢索數據的查詢。視圖是基於表或另外一個視圖的邏輯表,視圖沒有本身的數據，它本身沒有存儲的段。經過建立表的視圖能夠顯示數據的邏輯子集或組合，視圖能夠按每一個用戶不一樣的視角去縱向或者橫向查詢和顯示數據子集。

視圖的優勢：

（1）簡化用戶操做：

視圖不只能夠簡化用戶對數據的理解，也能夠簡化他們的操做。視圖機制使用戶能夠將注意力集中在所關心地數據上。若是這些數據不是直接來自基本表，則能夠經過定義視圖，使數據庫看起來結構簡單、清晰，而且能夠簡化用戶的的數據查詢操做。

（2）用戶能以多種角度看待同一數據：

使不一樣的用戶以不一樣的方式看待同一數據，當許多不一樣種類的用戶共享同一個數據庫時，這種靈活性是很是必要的。

（3）對重構數據庫提供了必定程度的邏輯獨立性：

視圖可使應用程序和數據庫表在必定程度上獨立。數據的物理獨立性是指用戶的應用程序不依賴於數據庫的物理結構。數據的邏輯獨立性是指當數據庫重構造時，如增長新的關係或對原有的關係增長新的字段，用戶的應用程序不會受影響。層次數據庫和網狀數據庫通常能較好地支持數據的物理獨立性，而對於邏輯獨立性則不能徹底的支持。

（4）安全性，對機密數據提供安全保護：

經過視圖用戶只能查詢和修改他們所能見到的數據。

視圖的缺點：

（1）性能差：

把視圖查詢轉化成對基本表的查詢，若是這個視圖是由一個複雜的多表查詢所定義，那麼，即便是視圖的一個簡單查詢，sql server也要把它變成一個複雜的結合體，須要花費必定的時間。

（2）修改限制：

當用戶試圖修改試圖的某些信息時，數據庫必須把它轉化爲對基本表的某些信息的修改，對於簡單的試圖來講，這是很方便的，可是，對於比較複雜的試圖，多是不可修改的。

視圖使用場景：

（1）權限控制的時候。當用戶須要查詢未受權的數據表且又須要部分數據表的部分列進行邏輯處理，不但願用戶訪問表中某些含敏感信息的列。

（2）關鍵信息來源於多個複雜關聯表，能夠建立視圖提取咱們須要的信息，簡化操做；

視圖的分類：

（1）關係視圖：

它屬於數據庫對象的一種，也就是最多見的一種關聯查詢；

（2）內嵌視圖：

它不屬於任何用戶，也不是對象，建立方式與普通視圖徹底不一樣，不具備可複用性，不能經過數據字典獲取數據；

（3）對象視圖：

它是基於表對象類型的視圖，特性是繼承、封裝等可根據須要構建對象類型封裝複雜查詢(官方:爲了迎合對象類型而重建數據表是不實現的)；

（4）物化視圖：

它主要用於數據庫的容災(備份)，實體化的視圖可存儲和查詢，經過DBLink鏈接在主數據庫物化視圖中複製，當主庫異常備庫接管實現容災；

---

 三個範式？

待補充。。。