MySQL 數據庫表分區.

MySQL 數據庫在 5.1 版本時添加了對分區（partitioning）的支持。分區的過程是將一個表或索引分解成多個更小、更可管理的部分。就訪問數據庫的應用而言，從邏輯上來說，只有一個表或一個索引，可是在物理上這個表或索引可能由數十個物理分區組成。

MySQL 分區功能並非在存儲引擎層完成的，所以不是隻有 InnoDB 存儲引擎支持分區，常見的存儲引擎 MyISAM、NDB 等都支持。

MySQL 數據庫支持的分庫類型爲水平分區（指將同一表中不一樣行的記錄分配到不一樣的物理文件中），並不支持垂直分區（指將同一表中不一樣列的記錄分配到不一樣的物理文件中）。

MySQL 數據庫的分區是局部分區索引，一個分區中既存放了數據又存放了索引。而全局分區是指，數據存放在各個分區中，可是全部數據的索引放在一個對象中。MySQL 數據庫目前不支持全局分區。

MySQL 查看數據庫分區。

SHOW VARIABLES LIKE '%partitions%';

MySQL 數據庫支持如下幾種類型的分區。¹ 若是表中存在主鍵/惟一索引時，分區列必須是主鍵/惟一索引的一個組成部分。² 對於 RANGE、LIST、HASH 和 KEY 這四種分區中，分區的條件是：數據必須是整型，若是不是整型，那應該須要經過函數將其轉化爲整型，如 YEAR(),TO_DAYS(),MONTH() 等函數。

• RANGE 分區：行數據基於屬於一個給定連續區間的列值被放入分區。
• LIST 分區：和 RANGE 分區相似，只是 LIST 分區面向的是離散的值。
• HASH 分區：根據用戶自定義的表達式（能夠僅僅是字段列名）的返回值來進行分區，返回值不能爲負數。
• LINEAR HASH 分區：線性 HASH 分區，使用的一個線性的2的冪（powers-of-two）算法來肯定新行插入到分區的什麼位置。LINEAR HASH 分區的優勢在於，增長、刪除、合併和拆分分區將變得更加快捷，這有利於處理含有大量數據的表。缺點在於，與 HASH 分區相比，各個分區間數據的分佈可能不太均衡。
• KEY 分區：和 HASH 分區相似，不過是根據 MySQL 數據庫內部提供的哈希函數來進行分區。
• LINEAR KEY 分區：和 LINEAR HASH 相似，分區的編號是經過2的冪（powers-of-two）算法獲得的。
• COLUMNS 分區：¹ 5.5 版本後開始支持，可視爲 RANGE 分區和 LIST 分區的一種進化，能夠直接使用非整型的數據進行分區，分區根據類型直接比較而得，不須要轉化爲整型。² 此外，RANGE COLUMNS 分區能夠對多個列的值進行分區。³ 對於以前的 RANGE 和 LIST 分區，用戶能夠用 RANGE COLUMNS 和 LIST COLUMNS 分區進行很好的代替。

子分區（subpartitioning）是在分區的基礎上再進行分區，有時也稱爲這種分區爲複合分區（composite partitioning）。MySQL 數據庫容許在 RANGE 和 LIST 的分區上再進行 HASH 或 KEY 的子分區。進行子分區後，分區的數量應該爲（分區數量 X 子分區數量）個。

MySQL 數據庫容許對 NULL 值作分區，視 NULL 值小於任何一個非 NULL 值（和 ORDER BY 處理 NULL 值的規則一致）。

對於 OLAP（在線分析處理） 的應用，分區的確是能夠很好地提升查詢的性能，由於 OLAP 應用大多數查詢須要頻繁地掃描一張很大的表。假設有一張 1 億行的表，其中有一個時間戳屬性列。用戶的查詢依據時間爲維度，若是按照時間戳進行分區，則只須要掃描對應的分區便可。

對於 OLTP（在線事務處理）的應用，一般不可能會獲取一張大表中 10% 的數據，大部分都是經過索引返回幾條記錄便可。所以分區應該很是當心，對於一張大表，通常的 B+ 樹須要 2~3 次 IO 就能檢索到數據。經過根據主鍵 ID 作 10 個 HASH 的分區後，對於查詢就須要掃描全部的 10 個分區，這無疑加劇了 IO 的負擔。

咱們經過 Navicat 來操做下數據庫分區，表 -> 右鍵點擊'設計表' -> 選項 -> 分割區，能夠看到以下內容。

來看看分區後，磁盤中 MySQL 數據庫是怎麼存儲的。

經過 EXPLAIN 分析數據檢索的分區。

EXPLAIN PARTITIONS SELECT * FROM t_materiel_config