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

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

優點：

1. 類似於封裝，簡化操作；
2. 不用反覆建立一系列處理步驟，保證了資料的完整性；
3. 通過儲存過程能夠使沒有許可權的使用者在控制之下間接地存取資料庫，從而確保資料的安全。
4. 簡化對變動的管理，安全；
5. 儲存過程是一個編譯過的程式碼塊，速度快，效能高；

缺點：

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

索引是什麼？有什麼作用？以及優缺點？使用索引查詢一定能提高查詢效能嗎？

索引是儲存引擎用於快速找到記錄的一種資料結構,索引類似一本書的目錄,我們根據目錄可以快速的查詢到我們感興趣的內容。索引就是儲存引擎的目錄,如果沒有索引儲存引擎必須遍歷整個資料庫表來查詢符合條件的記錄。一般來說，索引的建立和優化應該是提升查詢效能最有效的手段。

優點：

（1）通過建立唯一性索引，可以保證資料庫表中每一行資料的唯一性。
（2）可以大大加快 資料的檢索速度，這也是建立索引的最主要的原因。
（3）可以加速表和表之間的連線，特別是在實現資料的參考完整性方面特別有意義。

缺點：

（1）建立索引和維護索引要耗費時間，這種時間隨著資料 量的增加而增加。
（2）索引需要佔物理空間，除了資料表佔資料空間之外，每一個索引還要佔一定的物理空間，如果要建立聚簇索引，那麼需要的空間就會更大。
（3）當對錶中的資料進行增加、刪除和修改的時候，索引也要動態的維護，這樣就降低了資料的維護速度。

使用索引查詢不一定能提高查詢效能。通過索引查詢資料比全表掃描要快.但是我們也必須付出代價：索引需要空間來儲存,也需要定期維護, 每當有記錄在表中增減或索引列被修改時,索引本身也會被修改. 這意味著每條記錄的INSERT,DELETE,UPDATE將為此多付出4,5 次的磁碟I/O. 因為索引需要額外的儲存空間和處理,那些不必要的索引反而會使查詢反應時間變慢.使用索引查詢不一定能提高查詢效能,索引範圍查詢(INDEX RANGE SCAN)適用於兩種情況:

• 基於一個範圍的檢索,一般查詢返回結果集小於表中記錄數的30%
• 基於非唯一性索引的檢索

什麼是事務？

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

資料庫的樂觀鎖和悲觀鎖？

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

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

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

悲觀鎖：

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

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

如果成功加鎖，那麼就可以對記錄做修改，事務完成後就會解鎖了。

其間如果有其他對該記錄做修改或加排他鎖的操作，都會等待我們解鎖或直接丟擲異常。

優點與不足

悲觀併發控制實際上是“先取鎖再訪問”的保守策略，為資料處理的安全提供了保證。但是在效率方面，處理加鎖的機制會讓資料庫產生額外的開銷，還有增加產生死鎖的機會；另外，在只讀型事務處理中由於不會產生衝突，也沒必要使用鎖，這樣做只能增加系統負載；還有會降低了並行性，一個事務如果鎖定了某行資料，其他事務就必須等待該事務處理完才可以處理那行數

樂觀鎖:

在關係資料庫管理系統裡，樂觀併發控制（“樂觀鎖”，“OCC”）是一種併發控制的方法。它假設多使用者併發的事務在處理時不會彼此互相影響，各事務能夠在不產生鎖的情況下處理各自影響的那部分資料。在提交資料更新之前，每個事務會先檢查在該事務讀取資料後，有沒有其他事務又修改了該資料。如果其他事務有更新的話，正在提交的事務會進行回滾。樂觀事務控制最早是由孔祥重（H.T.Kung）教授提出。

相對於悲觀鎖，在對資料庫進行處理的時候，樂觀鎖並不會使用資料庫提供的鎖機制。一般的實現樂觀鎖的方式就是記錄資料版本。資料版本,為資料增加的一個版本標識。當讀取資料時，將版本標識的值一同讀出，資料每更新一次，同時對版本標識進行更新。當我們提交更新的時候，判斷資料庫表對應記錄的當前版本資訊與第一次取出來的版本標識進行比對，如果資料庫表當前版本號與第一次取出來的版本標識值相等，則予以更新，否則認為是過期資料。實現資料版本有兩種方式，第一種是使用版本號，第二種是使用時間戳。

優點與不足

樂觀併發控制相信事務之間的資料競爭(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連線在主資料庫物化檢視中複製，當主庫異常備庫接管實現容災；

 三個正規化？

待補充。。。