【文章內容簡介】 39。9999123139。, job_code INT, store_id INT)PARTITION BY HASH(YEAR(hired))PARTITIONS 4；“expr”還可以是MySQL 中有效的任何函數(shù)或其他表達式，只要它們返回一個既非常數(shù)、也非隨機數(shù)的整數(shù)。（換句話說，它既是變化的但又是確定的）。但是應當記住，每當插入或更新（或者可能刪除）一行，這個表達式都要計算一次；這意味著非常復雜的表達式可能會引起性能問題，尤其是在執(zhí)行同時影響大量行的運算（例如批量插入）的時候。 最有效率的哈希函數(shù)是只對單個表列進行計算，并且它的值隨列值進行一致地增大或減小，因為這考慮了在分區(qū)范圍上的“修剪”。也就是說，表達式值和它所基于的列的值變化越接近，MySQL就可以越有效地使用該表達式來進行HASH分區(qū)。 例如，“date_col” 是一個DATE（日期）類型的列，那么表達式TO_DAYS(date_col)就可以說是隨列“date_col”值的變化而發(fā)生直接的變化，因為列“date_col”值的每個變化，表達式的值也將發(fā)生與之一致的變化。而表達式YEAR(date_col)的變化就沒有表達式TO_DAYS(date_col)那么直接，因為不是列“date_col”每次可能的改變都能使表達式YEAR(date_col)發(fā)生同等的改變。即便如此，表達式YEAR(date_col)也還是一個用于 哈希函數(shù)的、好的候選表達式，因為它隨列date_col的一部分發(fā)生直接變化，并且列date_col的變化不可能引起表達式YEAR(date_col)不成比例的變化。作為對照，假定有一個類型為整型（INT）的、列名為“int_col”的列?，F(xiàn)在考慮表達式“POW(5int_col,3) + 6”。這對于哈希函數(shù)就是一個不好的選擇，因為“int_col”值的變化并不能保證表達式產生成比例的變化。列 “int_col”的值發(fā)生一個給定數(shù)目的變化，可能會引起表達式的值產生一個很大不同的變化。例如，把列“int_col”的值從5變?yōu)?，表達式的值將產生“－1”的改變，但是把列“int_col”的值從6變?yōu)?時，表達式的值將產生“－7”的變化。換句話說，如果列值與表達式值之比的曲線圖越接近由等式“y=nx（其中n為非零的常數(shù)）描繪出的直線，則該表達式越適合于 哈希。這是因為，表達式的非線性越嚴重，分區(qū)中數(shù)據產生非均衡分布的趨勢也將越嚴重。理論上講，對于涉及到多列的表達式，“修剪（pruning）”也是可能的，但是要確定哪些適于 哈希是非常困難和耗時的?；谶@個原因，實際上不推薦使用涉及到多列的哈希表達式。 當使用了“PARTITION BY HASH”時，MySQL將基于用戶函數(shù)結果的模數(shù)來確定使用哪個編號的分區(qū)。換句話，對于一個表達式“expr”，將要保存記錄的分區(qū)編號為N ，其中“N = MOD(expr, num)”。例如，假定表t1 定義如下，它有4個分區(qū)： CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY HASH( YEAR(col3) ) PARTITIONS 4；如果插入一個col3列值為39。2005091539。的記錄到表t1中，那么保存該條記錄的分區(qū)確定如下： MOD(YEAR(39。2005090139。),4)= MOD(2005,4)= 1MySQL 還支持一個被稱為“l(fā)inear hashing（線性哈希功能）”的變量，它使用一個更加復雜的算法來確定新行插入到已經分區(qū)了的表中的位置。關于這種算法的描述，“LINEAR HASH分區(qū)” 。 每當插入或更新一條記錄，用戶函數(shù)都要計算一次。當刪除記錄時，用戶函數(shù)也可能要進行計算，這取決于所處的環(huán)境。 注釋：如果將要分區(qū)的表有一個唯一的鍵，那么用來作為HASH用戶函數(shù)的自變數(shù)或者主鍵的column_list的自變數(shù)的任意列都必須是那個鍵的一部分。. LINEAR HASH分區(qū)MySQL還支持線性哈希功能，它與常規(guī)哈希的區(qū)別在于，線性哈希功能使用的一個線性的2的冪（powersoftwo）運算法則，而常規(guī) 哈希使用的是求哈希函數(shù)值的模數(shù)。線性哈希分區(qū)和常規(guī)哈希分區(qū)在語法上的唯一區(qū)別在于，在“PARTITION BY” 子句中添加“LINEAR”關鍵字，如下面所示：CREATE TABLE employees ( id INT NOT NULL, fname VARCHAR(30), lname VARCHAR(30), hired DATE NOT NULL DEFAULT 39。1970010139。, separated DATE NOT NULL DEFAULT 39。9999123139。, job_code INT, store_id INT)PARTITION BY LINEAR HASH(YEAR(hired))PARTITIONS 4；假設一個表達式expr, 當使用線性哈希功能時，記錄將要保存到的分區(qū)是num 個分區(qū)中的分區(qū)N，其中N是根據下面的算法得到： 1. 、2的冪，我們把這個值稱為V ，它可以通過下面的公式得到： 2. V = POWER(2, CEILING(LOG(2, num)))（例如，假定num是13。那么LOG(2,13)。 CEILING()就是4，則V = POWER(2,4), 即等于16）。 3. 設置 N = F(column_list) amp。 (V 1). 4. 當 N = num: 設置 V = CEIL(V / 2) 設置 N = N amp。 (V 1) 例如，假設表t1，使用線性哈希分區(qū)且有4個分區(qū)，是通過下面的語句創(chuàng)建的：CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE) PARTITION BY LINEAR HASH( YEAR(col3) ) PARTITIONS 6。現(xiàn)在假設要插入兩行記錄到表t1中，其中一條記錄col3列值為39。2003041439。，另一條記錄col3列值為39。1998101939。第一條記錄將要保存到的分區(qū)確定如下：V = POWER(2, CEILING(LOG(2,7))) = 8N = YEAR(39。2003041439。) amp。 (8 1) = 2003 amp。 7 = 3 (3 = 6 為假（FALSE）: 記錄將被保存到3號分區(qū)中)第二條記錄將要保存到的分區(qū)序號計算如下： V = 8N = YEAR(39。1998101939。) amp。 (81) = 1998 amp。 7 = 6 (6 = 4 為真（TRUE）: 還需要附加的步驟) N = 6 amp。 CEILING(5 / 2) = 6 amp。 3 = 2 (2 = 4 為假（FALSE）: 記錄將被保存到2分區(qū)中)按照線性哈希分區(qū)的優(yōu)點在于增加、刪除、合并和拆分分區(qū)將變得更加快捷，有利于處理含有極其大量（1000吉）數(shù)據的表。它的缺點在于，與使用常規(guī)HASH分區(qū)得到的數(shù)據分布相比，各個分區(qū)間數(shù)據的分布不大可能均衡。. KEY分區(qū)按照KEY進行分區(qū)類似于按照HASH分區(qū)，除了HASH分區(qū)使用的用戶定義的表達式，而KEY分區(qū)的 哈希函數(shù)是由MySQL 服務器提供。MySQL 簇（Cluster）使用函數(shù)MD5()來實現(xiàn)KEY分區(qū)；對于使用其他存儲引擎的表，服務器使用其自己內部的 哈希函數(shù)，這些函數(shù)是基于與PASSWORD()一樣的運算法則。 “CREATE TABLE ... PARTITION BY KEY”的語法規(guī)則類似于創(chuàng)建一個通過HASH分區(qū)的表的規(guī)則。它們唯一的區(qū)別在于使用的關鍵字是KEY而不是HASH，并且KEY分區(qū)只采用一個或多個列名的一個列表。 通過線性KEY分割一個表也是可能的。下面是一個簡單的例子： CREATE TABLE tk ( col1 INT NOT NULL, col2 CHAR(5), col3 DATE) PARTITION BY LINEAR KEY (col1)PARTITIONS 3。在KEY分區(qū)中使用關鍵字LINEAR和在HASH分區(qū)中使用具有同樣的作用，分區(qū)的編號是通過2的冪（powersoftwo）算法得到，而不是通過模數(shù)算法。關于該算法及其蘊涵式的描述請參考 ，“LINEAR HASH分區(qū)” 。 . 子分區(qū)子分區(qū)是分區(qū)表中每個分區(qū)的再次分割。例如，考慮下面的CREATE TABLE 語句： CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE(YEAR(purchased)) SUBPARTITION BY HASH(TO_DAYS(purchased)) SUBPARTITIONS 2 ( PARTITION p0 VALUES LESS THAN (1990), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE )；表ts 有3個RANGE分區(qū)。這3個分區(qū)中的每一個分區(qū)——p0, p1, 和 p2 ——又被進一步分成了2個子分區(qū)。實際上，整個表被分成了3 * 2 = 6個分區(qū)。但是，由于PARTITION BY RANGE子句的作用，這些分區(qū)的頭2個只保存“purchased”列中值小于1990的那些記錄。 在MySQL ，對于已經通過RANGE或LIST分區(qū)了的表再進行子分區(qū)是可能的。子分區(qū)既可以使用HASH希分區(qū)，也可以使用KEY分區(qū)。這也被稱為復合分區(qū)（posite partitioning）。 為了對個別的子分區(qū)指定選項，使用SUBPARTITION 子句來明確定義子分區(qū)也是可能的。例如，創(chuàng)建在前面例子中給出的同一個表的、一個更加詳細的方式如下： CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE(YEAR(purchased)) SUBPARTITION BY HASH(TO_DAYS(purchased)) ( PARTITION p0 VALUES LESS THAN (1990) ( SUBPARTITION s0, SUBPARTITION s1 ), PARTITION p1 VALUES LESS THAN (2000) ( SUBPARTITION s2, SUBPARTITION s3 ), PARTITION p2 VALUES LESS THAN MAXVALUE ( SUBPARTITION s4, SUBPARTITION s5 ) )。幾點要注意的語法項： 每個分區(qū)必須有相同數(shù)量的子分區(qū)。 如果在一個分區(qū)表上的任何分區(qū)上使用SUBPARTITION 來明確定義任何子分區(qū)，那么就必須定義所有的子分區(qū)。換句話說，下面的語句將執(zhí)行失?。? CREATE TABLE ts (id INT, purchased DATE) PARTITION BY RANGE(YEAR(purchased)) SUBPARTITION BY HASH(TO_DAYS(purchased)) ( PARTITION p0 VALUES LESS THAN (1990) ( SUBPARTITION s0, SUBPARTITION s1 ), PARTITION p1 VALUES LESS THAN (2000), PARTITION p2 VALUES LESS THAN MAXVALUE ( SUBPARTITION s2, SUBPARTITION s3 ) )；即便這個語句包含了一個SUBPARTITIONS 2子句，但是它仍然會執(zhí)行失敗。 每個SUBPARTITION 子句必須包括 (至少)子分區(qū)的一個名字。否則，你可能要對該子分區(qū)設置任何你所需要的選項，或者允許該子分區(qū)對那些選項采用其默認的設置。 在每個分區(qū)內，子分區(qū)的名字必須是唯一的，但是在整個表中，沒有必要保持唯一。例如，下面的CREATE TABLE 語句是有效的： CREATE TABLE ts (id INT, purchased DATE)1