一.分割槽表

在下面的場景中，分割槽可以起到非常大的作用:

 分割槽表本身也有一些限制，下面是其中比較重要的幾點:

 1.分割槽表的原理

分割槽表由多個相關的底層表實現，這些底層表也是由控制代碼物件(Handlerobject)表示，所以我們也可以直接訪問各個分割槽。儲存引擎管理分割槽的各個底層表和管理普通表一樣（所有的底層表都必須使用相同的儲存引擎)，分割槽表的索引只是在各個底層表上各自加上一個完全相同的索引。從儲存引擎的角度來看，底層表和一個普通表沒有任何不同，儲存引擎也無須知道這是一個普通表還是一個分割槽表的一部分。
分割槽表上的操作按照下面的操作邏輯進行:

SELECT查詢

INSERT操作
當寫入一條記錄時，分割槽層先開啟並鎖住所有的底層表，然後確定哪個分割槽接收這條記錄，再將記錄寫入對應底層表。
DELETE操作
當刪除一條記錄時，分割槽層先開啟並鎖住所有的底層衣，然石傭疋效掂對應P刀一'最後對相應底層表進行刪除操作。
UPDATE操作
當更新一條記錄時，分割槽層先開啟並鎖住所有的底層表，MySQL先確定需要更新的記錄在哪個分割槽，然後取出資料並更新，再判斷更新後的資料應該放在哪個分割槽，最後對底層表進行寫入操作，並對原資料所在的底層表進行刪除操作。

2.分割槽表的型別

MySQL支援多種分割槽表。我們看到最多的是根據範圍進行分割槽，每個分割槽儲存落在某個範圍的記錄，分割槽表示式可以是列，也可以是包含列的表示式。例如，下表就可以將每一年的銷售額存放在不同的分割槽裡:

 3.如何使用分割槽表

為了保證大資料量的可擴充套件性，一般有下面兩個策略:

全量掃描資料，不要任何索引。
可以使用簡單的分割槽方式存放表，不要任何索引，根據分割槽的規則大致定位需要的資料位置。只要能夠使用WHERE條件，將需要的資料限制在少數分割槽中，則效率是很高的。當然，也需要做一些簡單的運算保證查詢的響應時間能夠滿足需求。使用該策略假設不用將資料完全放入到記憶體中，同時還假設需要的資料全都在磁碟上，因為記憶體相對很小，資料很快會被擠出記憶體，所以快取起不了任何作用。這個策略適用於以正常的方式訪問大量資料的時候。警告:後面我們會詳細解釋，必須將查詢需要掃描的分割槽個數限制在一個很小的數量。

NULL值會使分割槽過濾無效

分割槽列和索引列不匹配

選擇分割槽的成本可能很高

開啟並鎖住所有底層表的成本可能很高

維護分割槽的成本可能很高

5.查詢優化

引入分割槽給查詢優化帶來了一些新的思路（同時也帶來新的bug)。分割槽最大的優點就是優化器可以根據分割槽函式來過濾一些分割槽。根據粗粒度索引的優勢，通過分割槽過濾通常可以讓查詢掃描更少的資料（在某些場景下)。所以，對於訪問分割槽表來說，很重要的一點是要在WHERE條件中帶入分割槽列，有時候即使看似多餘的也要帶上，這樣就可以讓優化器能夠過濾掉無須訪問的分割槽。如果沒有這些條件，MySQL就需要讓對應儲存引擎訪問這個表的所有分割槽，如果表非常大的話，就可能會非常慢。

6.合併表

二.檢視

1.可更新檢視

可更新檢視(updatable view)是指可以通過更新這個檢視來更新檢視涉及的相關表。只要指定了合適的條件，就可以更新、刪除甚至向檢視中寫入資料。

2.檢視對效能的影響

3.檢視的限制

三.外來鍵約束

四.在MySQL內部儲存程式碼

MySQL允許通過觸發器、儲存過程、函式的形式來儲存程式碼。從MySQL 5.1開始，還可以在定時任務中存放程式碼，這個定時任務也被稱為“事件”。儲存過程和儲存函式都被統稱為“儲存程式”。

五.遊標