什么是存儲過程？有哪些優缺點？
存儲過程簡單來說就是為了以后使用而保存的一條或多條預編譯SQL語句，這些語句塊像一個方法一樣執行一些功能。
優點：
- 類似於封裝，簡化操作；
- 不用反復建立一系列處理步驟，保證了數據的完整性；
- 通過存儲過程能夠使沒有權限的用戶在控制之下間接地存取數據庫，從而確保數據的安全。
- 簡化對變動的管理，安全；
- 存儲過程是一個編譯過的代碼塊，速度快，性能高；
缺點：
- SQL本身是一種結構化查詢語言，但不是OO的，本質上還是過程化的，面對復雜的業務邏輯，過程化的處理會很吃力；
- 存儲過程的編寫比基本SQL語句復雜，需要較高的技能
- 可能沒有創建存儲過程的權限
索引是什么？有什么作用？以及優缺點？使用索引查詢一定能提高查詢性能嗎？
索引是存儲引擎用於快速找到記錄的一種數據結構,索引類似一本書的目錄,我們根據目錄可以快速的查找到我們感興趣的內容。索引就是存儲引擎的目錄,如果沒有索引存儲引擎必須遍歷整個數據庫表來查詢符合條件的記錄。一般來說，索引的建立和優化應該是提升查詢性能最有效的手段。
優點：
（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連接在主數據庫物化視圖中復制，當主庫異常備庫接管實現容災；
三個范式？
待補充。。。