レンジによってパーティショニングされたテーブルは、特定のレンジにおいて行のパーティショニング表現値が置かれるように、分割されます。レンジは連続していますがかぶることは無く、VALUES LESS THAN 演算子を使用して定義されます。次のいくつかの例では、ユーザが20のビデオレンタル店の個人情報を含む1から20のテーブルを作成しているとします。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
);

このテーブルは、ユーザのニーズによってさまざまな方法でレンジによる分割を行うことができます。1つには、store_id カラムを使用した方法があります。たとえば、PARTITION BY RANGE 節を使用して、4方法でテーブルを分割すると決めたとします。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN (21)
);

この分割スキーマでは、p0 分割に記憶されるのは店舗1-5で働く店員を含む行で、p1 分割に記憶されるのは店舗6-10の店員になります。各分割は小から大まで順番どおりに分割が分けられていることに注目してください。これは PARTITION BY RANGE 構文の要求です。switch ... case、C、Javaなどと同義であると考えていいでしょう。

(72, 'Michael', 'Widenius', '1998-06-25', NULL, 13) データを含む新しい行が p2 分割に挿入されていることは断定できますが、チェーンに 21 番目の店舗が追加された時はどうでしょう。このスキーマでは、store_id が20よりも大きい行をカバーしているというルールが無いため、サーバが何処に情報を置くかを判断しかねるため、エラーが発生します。.「キャッチオール」 VALUES LESS THAN 節を CREATE TABLE ステートメントで使用することによって、明確に挙げられる最高値よりも高い値全てに対応することができます。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

MAXVALUE はありうる最高の整数値を表しています。store_id カラム値が16かそれ以上のものは、 (定義される最高値) p3 分割に記憶されます。いずれ将来、? 25、30、もしくはさらに店舗が増えた時、? ALTER TABLE ステートメントを使用して21-25、26-30の店舗のために新しい分割を作成することができます。(方法に関しては、項15.3. 「パーティショニング管理」 を参照してください。)

同様に、雇用者コードに合わせてテーブルを分割することができます。?それは、job_codeカラム値によるレンジで可能になります。例えば、? 二桁雇用コードがストア店員、3桁コードが事務・サポート員に、そして4桁コードが基幹職を示している場合、?以下を使用して分割テーブルを作成することができます。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (job_code) (
    PARTITION p0 VALUES LESS THAN (100),
    PARTITION p1 VALUES LESS THAN (1000),
    PARTITION p2 VALUES LESS THAN (10000)
);

この場合、全てのストア店員に関する行は p0 分割で記憶され、事務・サポート要因に関する行は p1 、そして基幹職は p2 となります。

他にも VALUES LESS THAN 節で表現を使用することができます。ただし、, MySQLは表現の返される値を LESS THAN (<) 比較の一部として評価できることが前提となります。

店舗番号ごとにテーブルデータを分割するよりも、2つのうち１つの DATE カラムの表現を使用することができます。例えば、社員が会社を辞めた年度ごとに分割するとします。それは、YEAR(separated) の値となります。そのような分割スキーマを実装する CREATE TABLE ステートメントの例がここに記されています。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY RANGE ( YEAR(separated) ) (
    PARTITION p0 VALUES LESS THAN (1991),
    PARTITION p1 VALUES LESS THAN (1996),
    PARTITION p2 VALUES LESS THAN (2001),
    PARTITION p3 VALUES LESS THAN MAXVALUE
);

このスキーマでは、1991より前に辞めた社員に限って、行は p0 分割で記憶されています。1991から1995の間に辞めた社員はp1、1996 から2000の間に辞めた社員は p2 そして2000以降に辞めた社員は p3 で記憶されています。

レンジ分割は以下のような時に特に有用です。

MySQLのリスト分割は多くの点でレンジ分割に似ています。RANGE による分割同様、各分割は明確に定義されていなければいけません。決定的な違いは、リスト分割では、隣接する値のレンジ内のセットの1つとしてではなく、各分割は1セットの値のリストの中のカラム値メンバーシップによって定義・選択されます。これは PARTITION BYLIST (expr) によって実行されます。その時 expr はカラム値もしくは返される整数値に基づいたカラム値や表現であり、VALUES IN (value_list) の value_list はカンマによって分けられた整数のリストになります。

注:MySQL 5.1では、LIST による分割を行う時、整数のリストのみに対して照合(そして NULL ?項15.2.6. 「MySQL分割の NULL 値の取り扱い」 を参照してください)をすることが可能です。

分割がレンジによって定義されたケースとは異なり、リスト分割は特定の順番で宣言される必要はありません。さらに詳しい構文に関する情報については、項12.1.8. 「CREATE TABLE 構文」 を参照してください。

以下の例では、分割されるテーブルの基本的な定義は CREATE TABLE ステートメントによって提供されているものとします。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
);

(これは 項15.2.1. 「RANGE パーティショニング」 の例として使用されるテーブルと同様のものです。)

例えば、以下のテーブルの様に20のビデオレンタル店が4つのフランチャイズで分布されているとします。

同じ地域の店舗を示す行が同分割含まれるようテーブルを分割する場合は、以下の様に CREATE TABLE ステートメントを使用することができます。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY LIST(store_id) (
    PARTITION pNorth VALUES IN (3,5,6,9,17),
    PARTITION pEast VALUES IN (1,2,10,11,19,20),
    PARTITION pWest VALUES IN (4,12,13,14,18),
    PARTITION pCentral VALUES IN (7,8,15,16)
);

これによって、テーブルから特定の地域の店舗の従業員情報を簡単に追加・削除することが可能になります。例えば、西地域の全店舗が別の会社に売られたとします。その地域で雇用されている従業員を示す全ての行は ALTER TABLE employees DROP PARTITION pWest; クエリを使用して削除することができ、これは同等の DELETE ステートメントの DELETE FROM employees WHERE store_id IN (4,12,13,14,18); よりはるかに効率よく実行することができます。

RANGE や HASH 分割のように、NULL か整数ではない値を持つカラムでテーブルを分割する場合、そのような値を返すカラムに基づいてパーティショニング表現を使用する必要があります。例えば、以下のように従業員データを含むテーブルが記されていたとします。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code CHAR(1),
    store_id INT
);

この employees テーブルのバージョンでは、雇用コードは数値ではなく文字になります。各文字が特定の職種に対応しており、同様の職種についている、もしくは同じ職場の従業員は同じ分割に含まれるよう、以下のスキーマでテーブルを分割したいとします。

値のリストでキャラクタ値がしようできないため、これらを整数もしくは NULL 等に変換する必要があります。このため、ASCII() 関数をカラム値に使用することができます。加えて、? 異なる時間帯、ロケーションでの異なるアプリケーションの使用により、? これらのコードは大文字、もしくは小文字になりえ、「割り振られていない」 を示す「空」 値は、NULL、空の文字列、もしくはスペースを表しているかもしれません。このスキーマを実装しているパーティションドテーブルが以下に示されています。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code CHAR(1),
    store_id INT
) 
PARTITION BY LIST(ASCII( UCASE(job_code) )) (
    PARTITION management VALUES IN(68, 77, 79, 80),
    PARTITION sales VALUES IN(66, 76, 83),
    PARTITION technical VALUES IN(65, 69, 71, 73, 84),
    PARTITION clerical VALUES IN(75, 78, 89),
    PARTITION support VALUES IN(67, 70, 74, 82, 86),
    PARTITION unassigned VALUES IN(NULL, 0, 32)
);

表現が分割値リストでは許可されていないため、照合される文字に関してASCIIコードをリストしなければいけません。ASCII(NULL) が NULL を返すことに注意してください。

重要もし分割値のリストに含まれないカラム値（もしくはパーティショニング表現が返す値）に行を挿入しようとした場合、INSERT クエリはエラーを表示し、失敗に終わります。例えば、先ほど概要の説明がされた LIST リスト分割スキーマでは、このクエリは失敗します。

INSERT INTO employees VALUES 
    (224, 'Linus', 'Torvalds', '2002-05-01', '2004-10-12', 'Q', 21);

失敗は、81 (大文字 'Q' ASCII のアスキーコード）が分割を定義する値のリストに含まれていないためおこります。値のリストに含まれない値を承認する、VALUES LESS THAN(MAXVALUE) と同義の 分割リストの 「キャッチオール」 定義は存在しません。つまり、照合する全ての値は、値のリスト中に存在していなければいけません。

RANGE 分割と同様に、LIST 分割とキー、ハッシュ分割を合わせることで合成分割を生成できます(サブ分割)。項15.2.5. 「サブ分割」 を参照してください。

HASH による分割は前もって決められた数の分割の中でデータを均等に割り振るために使用されます。 レンジやリスト分割では、どの分割にカラム値やカラム値のセットが記憶されるか特定しなければいけません。ハッシュ分割では、MySQLがこれを自動的に実行してくれるため、ハッシュされるカラム値に対してカラム値や表現と、パーティションドテーブルのパーティションの数だけ特定すれば事足ります。

HASH 分割を使用してテーブルを分割する場合、CREATE TABLE ステートメントに PARTITION BY HASH (expr) 節を付加する必要があります。この時、expr は整数を返す表現です。これは単純に、MySQLの整数タイプと同様のタイプのカラムの名前でけっこうです。加えて、PARTITIONS num 節で続かせるのが定石です。この時、num はパーティションドテーブルのパーティションの数を表現するネガティブ値ではない整数になります。

例えば、以下のステートメントは store_id カラムに対してハッシングを行い、4つのパーティションに分かれるテーブルを作成します。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH(store_id)
PARTITIONS 4;

PARTITIONS 節を含めない場合、パーティションの数はデフォルトで 1 となります。

PARTITIONS キーワードの続きに数字が使用されていない場合、構文エラーとなります。

expr に対して整数を返すSQL表現を使用することもできます。例えば、雇用年度に対して分割を行いたいとします。以下のようにできます。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY HASH( YEAR(hired) )
PARTITIONS 4;

非定数、非ランダム整数値を返すという条件をクリアしていれば、MySQLで有効な expr に対してどの関数でも表現でも使用することができます。(言い換えれば、多様性があっても、断言的でなければいけません。)ただし、行が挿入もしくは更新（削除）されるたび、この表現が評価されます。これは、特に多数の行に影響を及ぼすオペレーション（例えばバッチ挿入）を実行する際、きわめて複雑な表現はパフォーマンス問題を浮上させる可能性があります。

最も効率的なハッシュ関数では、単一のテーブルカラムに対して実行され、その値がカラム値に比例して増大、減少します。これにより、分割のレンジを 「pruning」 することができます。つまり、表現が基となるカラムの値に対して比例すればするほど、MySQLはその表現をハッシュ分割にその分だけ効率よく用いることができます。

たとえば、date_col が DATE のカラム型である場合、表現 TO_DAYS(date_col) は date_col の値に対して直接比例します。これは date_col の値が変更されるたびに、表現の値が一定の割合で変更されるからです。YEAR(date_col) 表現の date_col に対する変化は、TO_DAYS(date_col) に対する変化と比べて直接的ではありません。これは、date_col 内の変化の全てが YEAR(date_col) に対して同等の変更を促すとは限らないからです。それでも、YEAR(date_col) はハッシュ関数の優れた候補となります。date_col の一部と直接比例する上、date_col 内には YEAR(date_col) に対して不均衡な変化を促すものが無いからです。

逆に、INT 型を持つ int_col というカラムがあるとします。この表現 POW(5-int_col,3) + 6 を検討してください。これはハッシュ関数に使用するには優れた候補とはいえません。なぜなら、int_col の値に変化がおきた時、値の表現に対して比例する変化が起きる保証がないからです。int_col の値を変更すれば、表現の値にもさまざまな変化を促します。例えば int_col を 5 から 6 に変えると、表現の値に -1 という変化をもたらしますが、int_col の値を 6 から 7 に変えると、表現の値に -7 という変化をもたらします。

言い換えると、, グラフのカラム値に対して versus 表現の値が y=nx この時 n は 0 以外の定数という条件のもと直線をなぞるほど、その表現はハッシュにふさわしいものになります。これは、表現が非直線状的であればあるほど、パーティション内で割り振られるデータが不均衡になりがちであることと関係しています。

セオリーでは、「刈り込み」は1つ以上のカラム値を含む表現にも使用できますが、ふさわしい表現の特定は難しい上に、多くの時間を要します。このため、複数のカラムに対してハッシュ表現を使用することは推奨できません。

PARTITION BY HASH が使用される時　MySQL は num 分割のどのパーティションが使用されるかを、ユーザ関数の結果係数に基づいて断定します。言い換えれば、expr の表現に対して、レコードが記憶されたパーティションの番号は N であり、N = MOD(expr, num) となります。.例えば、テーブル t1 が以下の様に定義され、4のパーティションがあるとします。

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY HASH( YEAR(col3) )
    PARTITIONS 4;

t1 にレコードを挿入し、col3 値が '2005-09-15' の場合、それが記憶されるパーティションは以下の様に断定されます。

MOD(YEAR('2005-09-01'),4)
=  MOD(2005,4)
=  1

MySQL 5.1 は HASH 分割の変形である、linear hashing もサポートしており、これはパーティションドテーブルに新しい行を配置する際にさらに複雑なアルゴリズムを使用します。詳細については、 項15.2.3.1. 「LINEAR HASH 分割」 を参照してください。

レコードが挿入もしくは更新されるたびに、ユーザ関数は評価されます。それは ? 状況によって、? レコードが消去される際に評価されることもあります。

注:分割されるテーブルに UNIQUE キーがある場合、HASH ユーザ関数や KEY の column_list に対してアーギュメントとして提供されたカラムは、そのキーの一部出なければいけません。例外:この制限は NDBCluster 記憶エンジンを使用しているテーブルには当てはまりません。

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT,
    store_id INT
)
PARTITION BY LINEAR HASH( YEAR(hired) )
PARTITIONS 4;

CREATE TABLE t1 (col1 INT, col2 CHAR(5), col3 DATE)
    PARTITION BY LINEAR HASH( YEAR(col3) )
    PARTITIONS 6;

V = POWER(2, CEILING( LOG(2,7) )) = 8
N = YEAR('2003-04-14') & (8 - 1)
   = 2003 & 7
   = 3

(3 >= 6 is FALSE: record stored in partition #3)

V = 8
N = YEAR('1998-10-19') & (8-1)
  = 1998 & 7
  = 6

(6 >= 6 is TRUE: additional step required)

N = 6 & CEILING(5 / 2)
  = 6 & 3
  = 2

(2 >= 6 is FALSE: record stored in partition #2)

キーによる分割はハッシュによる分割と似ていますが、ハッシュ分割がユーザによって定義された表現を使用するところ、キー分割のハッシュ関数は MySQL サーバによって提供されます。MySQL クラスタはこのために MD5() を使用します。他のストレージエンジンを使用しているテーブルには、サーバは自身の PASSWORD() アルゴリズムに基づいた内部ハッシュ関数を使用します。

CREATE TABLE ... PARTITION BY KEY の構文ルールは、ハッシュによってパーティションドテーブルを作成するものと類似しています。最大の相違点は

リニアキーを使用してテーブルを分割することもできます。ここに単純な例を記します。

CREATE TABLE tk (
    col1 INT NOT NULL,
    col2 CHAR(5),
    col3 DATE
) 
PARTITION BY LINEAR KEY (col1)
PARTITIONS 3;

LINEAR を使用するのは KEY 分割に対しても HASH 分割に対しても同様の効果をもたらします。この時分割はモジュロ算術よりも二乗アルゴリズムを使用して分割番号が派生されます。アルゴリズムとその意味合いについては、 項15.2.3.1. 「LINEAR HASH 分割」 を参照してください。

サブ分割、? もしくは コンポジット分割 ? はパーティションドテーブルのパーティションをさらに分けることを指します。例えば、以下の 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 分割を含んでいます。これらの各分割 ? p0、p1、そして p2 ? はさらに2つのサブ分割に分けられます。結果的に、テーブル全体が 3 * 2 = 6 分割に分けられます。ただし、PARTITION BY RANGE 節の作動によって、最初の2つは purchased カラムで 1990 の値より少ないレコードのみが記憶されます。

MySQL 5.1 では、RANGE や LIST によってパーティションドテーブルをさらにサブ分割することが可能です。サブ分割は HASH または KEY 分割を用いることがあります。これは、コンポジット分割 とも呼ばれます。

SUBPARTITION 節を使用して各々のサブ分割のオプションを特定することで、サブ分割を定義することができます。例えば、以前の例通りの ts を回りくどく作成する場合。

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
        )
    );

構文的な注意点：

サブ分割はデータやインデックスを複数のディスク上分布するために特に大きなテーブルと使用することができます。例えば、/disk0、/disk1、/disk2 とつづく6つのディスクを重ねていたとします。以下の例を検討してください。

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 
                DATA DIRECTORY = '/disk0/data' 
                INDEX DIRECTORY = '/disk0/idx',
            SUBPARTITION s1 
                DATA DIRECTORY = '/disk1/data' 
                INDEX DIRECTORY = '/disk1/idx'
        ),
        PARTITION p1 VALUES LESS THAN (2000) (
            SUBPARTITION s2 
                DATA DIRECTORY = '/disk2/data' 
                INDEX DIRECTORY = '/disk2/idx',
            SUBPARTITION s3 
                DATA DIRECTORY = '/disk3/data' 
                INDEX DIRECTORY = '/disk3/idx'
        ),
        PARTITION p2 VALUES LESS THAN MAXVALUE (
            SUBPARTITION s4 
                DATA DIRECTORY = '/disk4/data' 
                INDEX DIRECTORY = '/disk4/idx',
            SUBPARTITION s5 
                DATA DIRECTORY = '/disk5/data' 
                INDEX DIRECTORY = '/disk5/idx'
        )
    );

この場合、データと各 RANGE インデックスごとに別のディスクが使用されています。他にもバリエーションが考えられます。例えば：

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 s0a 
                DATA DIRECTORY = '/disk0' 
                INDEX DIRECTORY = '/disk1',
            SUBPARTITION s0b 
                DATA DIRECTORY = '/disk2' 
                INDEX DIRECTORY = '/disk3'
        ),
        PARTITION p1 VALUES LESS THAN (2000) (
            SUBPARTITION s1a 
                DATA DIRECTORY = '/disk4/data' 
                INDEX DIRECTORY = '/disk4/idx',
            SUBPARTITION s1b 
                DATA DIRECTORY = '/disk5/data' 
                INDEX DIRECTORY = '/disk5/idx'
        ),
        PARTITION p2 VALUES LESS THAN MAXVALUE (
            SUBPARTITION s2a,
            SUBPARTITION s2b
        )
    );

ここでは、ストレージは以下のようになります。

MySQLでの分割は、カラム値であろうと、ユーザによって提供された表現であろうと、NULL をパーティショニング表現の値として禁じるようなことは一切しません。NULL 値を、整数を生み出す表現の値として使用することが許可されていますが、NULL は数値でないことを覚えておいてください。MySQL5.1.8より、分割は NULL を全ての非 NULL 値より少ないものと認めます。これは、ORDER BY でも同じです。

これにより、NULL の取り扱いは異なる分割の種類によって、予期せぬ事態を招くことがあります。これにより、この章では各MySQLの分割型が、行が記憶される分割を選択するさい、どのように NULL 値を取り扱うかを紹介し、例を取り上げます。

分割を判定するカラム値が NULL となるよう RANGE によりパーティションドテーブルに行を挿入した場合、 行は最も低いパーティションに挿入されます。例えば、以下の2つの実装、作成されたテーブルを記します。

mysql> CREATE TABLE t1 (
    ->     c1 INT, 
    ->     c2 VARCHAR(20)
    -> ) 
    -> PARTITION BY RANGE(c1) ( 
    ->     PARTITION p0 VALUES LESS THAN (0), 
    ->     PARTITION p1 VALUES LESS THAN (10), 
    ->     PARTITION p2 VALUES LESS THAN MAXVALUE 
    -> );
Query OK, 0 rows affected (0.09 sec)
 
mysql> CREATE TABLE t1 (
    ->     c1 INT, 
    ->     c2 VARCHAR(20)
    -> ) 
    -> PARTITION BY RANGE(c1) ( 
    ->     PARTITION p0 VALUES LESS THAN (-5), 
    ->     PARTITION p1 VALUES LESS THAN (0),  
    ->     PARTITION p1 VALUES LESS THAN (10), 
    ->     PARTITION p2 VALUES LESS THAN MAXVALUE 
    -> );
Query OK, 0 rows affected (0.09 sec)

mysql> INSERT INTO t1 VALUES (NULL, 'mothra');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO t2 VALUES (NULL, 'mothra');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM t1;
+------+--------+
| id   | name   |
+------+--------+
| NULL | mothra |
+------+--------+
1 row in set (0.00 sec)

mysql> SELECT * FROM t2;
+------+--------+
| id   | name   |
+------+--------+
| NULL | mothra |
+------+--------+
1 row in set (0.00 sec)

どのパーティションに行が記憶されているかは、ファイルシステムを検査し、分割と対応している .MYD ファイルのサイズを比較することで割り出すことができます。

/var/lib/mysql/test> ls -l *.MYD
-rw-rw----  1 mysql mysql 20 2006-03-10 03:27 t1#P#p0.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 03:17 t1#P#p1.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 03:17 t1#P#p2.MYD
-rw-rw----  1 mysql mysql 20 2006-03-10 03:27 t2#P#p0.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 03:17 t2#P#p1.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 03:17 t2#P#p2.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 03:17 t2#P#p3.MYD

(分割ファイルは table_name#P#partition_name.extension フォーマットにより名づけられます。t1#P#p0.MYD はテーブル t1 の分割 p0 データが記憶されているところです。注: MySQL 5.1.5以前には、これらのファイルはそれぞれ t1_p0.MYD や t2_p0.MYD と名づけられていました。この変化が更新に対してどういう影響を及ぼすかは、項C.1.11. 「Changes in release 5.1.6 (01 February 2006)」 とバグ#13437を参照してください。)

これらの行が各テーブルの最も低い分割に記憶されていたことを証明するには、これらの分割を削除し、SELECT ステートメントを起動します。

mysql> ALTER TABLE t1 DROP PARTITION p0;
Query OK, 0 rows affected (0.16 sec)

mysql> ALTER TABLE t2 DROP PARTITION p0;
Query OK, 0 rows affected (0.16 sec)

mysql> SELECT * FROM t1;
Empty set (0.00 sec)

mysql> SELECT * FROM t2;
Empty set (0.00 sec)

(ALTER TABLE ... DROP PARTITION に関する情報については、項12.1.2. 「ALTER TABLE 構文」 を参照してください。)

これはSQL関数を使用するパーティショニング表現に対しても同様です。例えば、以下のようなテーブルがあるとします。

CREATE TABLE tndate (
    id INT,
    dt DATE
)
PARTITION BY RANGE( YEAR(dt) ) (
    PARTITION p0 VALUES LESS THAN (1990),
    PARTITION p1 VALUES LESS THAN (2000),
    PARTITION p2 VALUES LESS THAN MAXVALUE
);

他の MySQL 関数同様、YEAR(NULL) は NULL を返します。NULL の dt カラム値を持つ行は、パーティショニング表現がそれ以外の値よりも少ない値に評価されたかのように扱われるため、 p0 分割に挿入される。

LIST によってパーティションドテーブルが、NULL 値を認めるのは、NULL を含む値のリストを使用して一部の分割が定義されている場合のみです。これの逆は、LIST によってパーティションドテーブルで、値のリスト行拒否で NULL を明確にしようしないため、以下のようなNULL 値のパーティショニング表現に至ります。

mysql> CREATE TABLE ts1 (
    ->     c1 INT,
    ->     c2 VARCHAR(20)
    -> )
    -> PARTITION BY LIST(c1) (
    ->     PARTITION p0 VALUES IN (0, 3, 6),
    ->     PARTITION p1 VALUES IN (1, 4, 7),
    ->     PARTITION p2 VALUES IN (2, 5, 8)
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO ts1 VALUES (9, 'mothra');
ERROR 1504 (HY000): Table has no partition for value 9

mysql> INSERT INTO ts1 VALUES (NULL, 'mothra');
ERROR 1504 (HY000): Table has no partition for value NULL

唯一 0 から 8 の間に c1 の値が含まれる行が ts1 に挿入可能です。NULL は 9 の様に、このレンジ外に位置します。NULL を含む値リストを持つテーブル ts2 や ts3 を、以下のとおり作成することができます。

mysql> CREATE TABLE ts2 (
    ->     c1 INT,
    ->     c2 VARCHAR(20)
    -> )
    -> PARTITION BY LIST(c1) (
    ->     PARTITION p0 VALUES IN (0, 3, 6),
    ->     PARTITION p1 VALUES IN (1, 4, 7),
    ->     PARTITION p2 VALUES IN (2, 5, 8),
    ->     PARTITION p3 VALUES IN (NULL)
    -> );
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE ts3 (
    ->     c1 INT,
    ->     c2 VARCHAR(20)
    -> )
    -> PARTITION BY LIST(c1) (
    ->     PARTITION p0 VALUES IN (0, 3, 6),
    ->     PARTITION p1 VALUES IN (1, 4, 7, NULL),
    ->     PARTITION p2 VALUES IN (2, 5, 8)
    -> );
Query OK, 0 rows affected (0.01 sec)

分割のために値のリストを定義している時、NULL は他の値と同様に扱えます。よって、VALUES IN (NULL) と VALUES IN (1, 4, 7, NULL) は両方有効です(VALUES IN (1, NULL, 4, 7)、VALUES IN (NULL, 1, 4, 7)、以下同様)。テーブル ts2 と ts3 両方に NULL を持つ行をカラム c1 に挿入することができます。

mysql> INSERT INTO ts2 VALUES (NULL, 'mothra');
Query OK, 1 row affected (0.00 sec)

mysql> INSERT INTO ts3 VALUES (NULL, 'mothra');
Query OK, 1 row affected (0.00 sec)

ファイルシステムを検査することで、テーブル ts2 の分割 p3 にはこれらステートメントの最初のものが挿入され、テーブル ts3 の分割 p1 には2番目のステートメントが挿入されたことを確認することができます。

/var/lib/mysql/test> ls -l ts2*.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 10:35 ts2#P#p0.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 10:35 ts2#P#p1.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 10:35 ts2#P#p2.MYD
-rw-rw----  1 mysql mysql 20 2006-03-10 10:35 ts2#P#p3.MYD

/var/lib/mysql/test> ls -l ts3*.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 10:36 ts3#P#p0.MYD
-rw-rw----  1 mysql mysql 20 2006-03-10 10:36 ts3#P#p1.MYD
-rw-rw----  1 mysql mysql  0 2006-03-10 10:36 ts3#P#p2.MYD

新しい例のとおり、これらファイルをリストするため、ユニックスオペレーティングシステム上で bash シェルを使用します。この件に関しては、ユーザのプラットフォームが提供するものを使用してください。たとえば、WindowsのOS上でDOSシェルを使用している場合、最後のリストと等価のものは C:\Program Files\MySQL\MySQL Server 5.1\data\test ディレクトリ内の dir ts3*.MYD コマンドを起動することで取得できる可能性があります。

このセクションの前部で紹介したとおり、削除し、SELECT を実行することで値の記憶に使用された分割を確認することができます。.

NULL は HASH や KEY によってパーティションドテーブルとは同様に取り扱われます。こういったケースでは、NULL 値を生み出すパーティショニング表現は返される値が０であるかのように扱われます。この動作を確認するには、HASH によってパーティションドテーブルを作成し、適当な値を含むレコードで実装させることでファイルシステムへの影響を調べることができます。たとえば、以下のステートメントで、test データベース内のテーブル th が作成されたとします。

mysql> CREATE TABLE th (
    ->     c1 INT,
    ->     c2 VARCHAR(20)
    -> )
    -> PARTITION BY HASH(c1)
    -> PARTITIONS 2;
Query OK, 0 rows affected (0.00 sec)

Linux上でのMySQLのRPMインストールを想定すると、このステートメントは2つの .MYD ファイルを /var/lib/mysql/test につくり、それは bash シェルで以下の様に現れます。

/var/lib/mysql/test> ls th*.MYD -l
-rw-rw----  1 mysql mysql 0 2005-11-04 18:41 th#P#p0.MYD
-rw-rw----  1 mysql mysql 0 2005-11-04 18:41 th#P#p1.MYD

各ファイルのサイズが0 バイトであることに注目してください。では、c1 カラム値が NULL の行を th に挿入して、その行が挿入されたことを認証してください。

mysql> INSERT INTO th VALUES (NULL, 'mothra');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM th;
+------+---------+
| c1   | c2      |
+------+---------+
| NULL | mothra  |
+------+---------+
1 row in set (0.01 sec)

どの整数 N にとっても、NULL MOD N の値は常に NULL になります。HASH や KEY によってパーティションドテーブルに関しては、この結果は正しい分割を 0 として確定するために扱われます。システムシェルに戻ると、(このため bash を使用します)、再度データファイルをリストすることで、値が最初の分割に挿入されたことを確認できます。(デフォルトで p0 と名づけられる)

var/lib/mysql/test> ls *.MYD -l
-rw-rw----  1 mysql mysql 20 2005-11-04 18:44 th#P#p0.MYD
-rw-rw----  1 mysql mysql  0 2005-11-04 18:41 th#P#p1.MYD

他のデータファイルに影響することなく（ディスク上でサイズを増大）、th#P#p0.MYD ファイルのみ、INSERT ステートメントが改良したことが確認できます。

重要MySQL 5.1.8以前では、RANGE 分割は、配置の断定に関して、パーティショニング表現値 NULL をゼロとして扱いました。(これを回避する方法は、ヌルを許容しないテーブルをデザインすることで、通常はカラムを NOT NULL と宣言することで実行しました)。この前期の動作による RANGE 分割スキーマがある場合、MySQL 5.1.8以降にアップグレードする時再実装しなければいけません。

パーティションの追加や削除が行われる点に関しては、レンジ分割もリスト分割もよく似ています。このため、これらのパーティションの管理をこのセクションで紹介します。ハッシュやキーでパーティショニングされたテーブルの使用については、項15.3.2. 「HASH や KEY パーティションの管理」 を参照してください。RANGE や LIST パーティションの削除は追加よりも単純なので、先にこちらを紹介します。

RANGE か LIST によってパーティションドテーブルからパーティションを削除するには、ALTER TABLE ステートメントを DROP PARTITION 節と使用することで達成できます。ここに単純な例を記します。すでにレンジで作成され、CREATE TABLE と INSERT ステートメントを使用して10のレコードで実装されたテーブルがあるとします。

mysql> CREATE TABLE tr (id INT, name VARCHAR(50), purchased DATE)
    ->     PARTITION BY RANGE( YEAR(purchased) ) (
    ->         PARTITION p0 VALUES LESS THAN (1990),
    ->         PARTITION p1 VALUES LESS THAN (1995),
    ->         PARTITION p2 VALUES LESS THAN (2000),
    ->         PARTITION p3 VALUES LESS THAN (2005)
    ->     );
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO tr VALUES
    ->     (1, 'desk organiser', '2003-10-15'),
    ->     (2, 'CD player', '1993-11-05'),
    ->     (3, 'TV set', '1996-03-10'),
    ->     (4, 'bookcase', '1982-01-10'),
    ->     (5, 'exercise bike', '2004-05-09'),
    ->     (6, 'sofa', '1987-06-05'),
    ->     (7, 'popcorn maker', '2001-11-22'),
    ->     (8, 'aquarium', '1992-08-04'),
    ->     (9, 'study desk', '1984-09-16'),
    ->     (10, 'lava lamp', '1998-12-25');
Query OK, 10 rows affected (0.01 sec)                  

どのアイテムが p2 分割に挿入されるべきかは、以下で確認できます。

mysql> SELECT * FROM tr
    -> WHERE purchased BETWEEN '1995-01-01' AND '1999-12-31';
+------+-----------+------------+
| id   | name      | purchased  |
+------+-----------+------------+
|    3 | TV set    | 1996-03-10 |
|   10 | lava lamp | 1998-12-25 |
+------+-----------+------------+
2 rows in set (0.00 sec)

p2 と名づけられた分割を削除するには、以下のコマンドを実行してください。

mysql> ALTER TABLE tr DROP PARTITION p2;
Query OK, 0 rows affected (0.03 sec)

注:MySQL 5.1 では、NDBCLUSTER ストレージ エンジンは ALTER TABLE ... DROP PARTITION をサポートしません。ただし、この章で紹介される他の ALTER TABLE 分割に関連する拡張子はサポートされます。

分割を削除する時、そのパーティション内で記憶されていたデータも全て削除される ことに注意してください。以前の SELECT クエリを再起動させることでこれを確認できます。

mysql> SELECT * FROM tr WHERE purchased 
    -> BETWEEN '1995-01-01' AND '1999-12-31';
Empty set (0.00 sec)

これにより、MySQL 5.1.10 では ALTER TABLE ...DROP PARTITION を実行する前にテーブルの DROP 権限があります。

テーブルの定義と分割スキーマを保持したまま分割からデータを削除したい場合、TRUNCATE TABLE コマンドを実行してください。（詳しくは 項12.2.9. 「TRUNCATE 構文」 をご確認ください。）

データを 失わずに、テーブルの分割を変更する場合、ALTER TABLE ...REORGANIZE PARTITION を代わりに使用してください。REORGANIZE PARTITION に関する情報については、以下か 項12.1.2. 「ALTER TABLE 構文」 を参照してください。

これで SHOW CREATE TABLE コマンドを実行すれば、テーブルの分割構造がどう変更したか確認できます。

mysql> SHOW CREATE TABLE tr\G
*************************** 1. row ***************************
       Table: tr
Create Table: CREATE TABLE `tr` (
  `id` int(11) default NULL,
  `name` varchar(50) default NULL,
  `purchased` date default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 
PARTITION BY RANGE ( YEAR(purchased) ) (
  PARTITION p0 VALUES LESS THAN (1990) ENGINE = MyISAM, 
  PARTITION p1 VALUES LESS THAN (1995) ENGINE = MyISAM, 
  PARTITION p3 VALUES LESS THAN (2005) ENGINE = MyISAM
)
1 row in set (0.01 sec)

'1995-01-01' と '2004-12-31' 間の purchased カラム値を変更されたテーブルに行挿入する時、p3 パーティションに記憶されます。以下の様に証明できます。

mysql> INSERT INTO tr VALUES (11, 'pencil holder', '1995-07-12');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT * FROM tr WHERE purchased 
    -> BETWEEN '1995-01-01' AND '2004-12-31';
+------+----------------+------------+
| id   | name           | purchased  |
+------+----------------+------------+
|   11 | pencil holder  | 1995-07-12 |
|    1 | desk organiser | 2003-10-15 |
|    5 | exercise bike  | 2004-05-09 |
|    7 | popcorn maker  | 2001-11-22 |
+------+----------------+------------+
4 rows in set (0.00 sec)

mysql> ALTER TABLE tr DROP PARTITION p3;
Query OK, 0 rows affected (0.03 sec)

mysql> SELECT * FROM tr WHERE purchased 
    -> BETWEEN '1995-01-01' AND '2004-12-31';
Empty set (0.00 sec)

ALTER TABLE ... DROP PARTITION の結果テーブルから削除された行の数は、同等の DELETE クエリによって処理された場合と違い、サーバによって報告されません。

LIST 分割の削除は、RANGE 分割の削除とと同様の ALTER TABLE ... DROP PARTITION 構文を使用します。ただし、テーブルの使用に対して、1つ重大な違いがあります。テーブルに、削除された分割を定義する値リストに含まれていた値を、行挿入することができません。(項15.2.2. 「LIST 分割」 で例を参照してください。)

以前にパーティションドテーブルに新しいレンジ、もしくはリスト分割を追加する場合は、ALTER TABLE ... ADD PARTITION ステートメントを使用してください。RANGE によって分割されているテーブルには、これをすることによって存在するパーティションのリストに新しい絵レンジを追加できます。例えば、ユーザの所属する機関のメンバーデータを含むパーティションドテーブルが、以下のようにあるとします。

CREATE TABLE members (
    id INT, 
    fname VARCHAR(25),
    lname VARCHAR(25), 
    dob DATE
)
PARTITION BY RANGE( YEAR(dob) ) (
    PARTITION p0 VALUES LESS THAN (1970),
    PARTITION p1 VALUES LESS THAN (1980),
    PARTITION p2 VALUES LESS THAN (1990)
);

例えば、さらに、メンバーの最低年齢が16とします。2005年に近づくと、1990年に生まれたメンバー（そしてその年以降）を受け付けていることに気づき始めるでしょう。members テーブルを改良して、1990-1999に生まれた新メンバーを表すことができます。

ALTER TABLE ADD PARTITION (PARTITION p3 VALUES LESS THAN (2000));

重要レンジによりパーティションドテーブルでは、分割のリストに新しい分割を追加するため、ADD PARTITION を使用することができます。このようにして、存在する分割のまえ、もしくは間に新しい分割を追加すると、以下のようなエラー表示となります。

mysql> ALTER TABLE members
     >     ADD PARTITION (
     >     PARTITION p3 VALUES LESS THAN (1960));
ERROR 1463 (HY000): VALUES LESS THAN value must be strictly ≫
   increasing for each partition

同じように、LIST によってパーティションドテーブルに新しいパーティションを追加することができます。例えば、以下の様に定義されたテーブルでは：

CREATE TABLE tt (
    id INT, 
    data INT
)
PARTITION BY LIST(data) (
    PARTITION p0 VALUES IN (5, 10, 15),
    PARTITION p1 VALUES IN (6, 12, 18)
);

data カラム値 7、14、そして 21 含む行を記憶する新しい分割を追加することができます。

ALTER TABLE tt ADD PARTITION (PARTITION p2 VALUES IN (7, 14, 21));

存在する分割の値リストに含まれる値を包含する新しい LIST 分割を追加することは できません。試みると、以下のエラーが発生します。

mysql> ALTER TABLE tt ADD PARTITION 
     >     (PARTITION np VALUES IN (4, 8, 12));
ERROR 1465 (HY000): Multiple definition of same constant ≫
                    in list partitioning

data カラム値 12 を含む行はすでにパーティション p1 に割り振られているため、テーブル tt に 12 を値リストに含む新しいパーティションを作成することはできません。これを達成するには、p1 を削除し、np を追加してから、改良された定義の新しい p1 を作成する必要があります。ただし、以前述べたとおり、p1 に記憶れた全てのデータの損失につながります。? 大抵、ユーザの意思とはかけ離れた結果となります。また、別の解決法で、新しい分割を含んだテーブルのコピーを作成し、かつデータを CREATE TABLE ...SELECT ... を使用して書き込み、古いテーブルを削除し新しいテーブルの名前をつけなおすことができますが、量の多いデータを取り扱っている時など、非常に多くの時間を要することがあります。加えて、これは高い有効性が求められている状況では、あまり推奨できる手段ではありません。

MySQL 5.1.6二始まり、以下の様に1つの ALTER TABLE ... ADD PARTITION ステートメントに複数の分割を追加することができます。

CREATE TABLE employees (
  id INT NOT NULL,
  fname VARCHAR(50) NOT NULL,
  lname VARCHAR(50) NOT NULL,
  hired DATE NOT NULL
)
PARTITION BY RANGE( YEAR(hired) ) (
  PARTITION p1 VALUES LESS THAN (1991),
  PARTITION p2 VALUES LESS THAN (1996),
  PARTITION p3 VALUES LESS THAN (2001),
  PARTITION p4 VALUES LESS THAN (2005)
);

ALTER TABLE employees ADD PARTITION (
    PARTITION p5 VALUES LESS THAN (2010), 
    PARTITION p6 VALUES LESS THAN MAXVALUE
);

幸い、MySQLのパーティショニング実装はデータを損失することなくパーティショニングを再定義する方法を提供しています。では、RANGE パーティショニングの例をいくつか見てみましょう。以下のように定義されている、members テーブルを思い出してください。

mysql> SHOW CREATE TABLE members\G
*************************** 1. row ***************************
       Table: members
Create Table: CREATE TABLE `members` (
  `id` int(11) default NULL,
  `fname` varchar(25) default NULL,
  `lname` varchar(25) default NULL,
  `dob` date default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 
PARTITION BY RANGE ( YEAR(dob) ) (
  PARTITION p0 VALUES LESS THAN (1970) ENGINE = MyISAM, 
  PARTITION p1 VALUES LESS THAN (1980) ENGINE = MyISAM, 
  PARTITION p2 VALUES LESS THAN (1990) ENGINE = MyISAM.
  PARTITION p3 VALUES LESS THAN (2000) ENGINE = MyISAM
)

例えば、1960年以前に生まれたメンバーを示す行を別のパーティションに移動させたいとします。すでに見たよう、ALTER TABLE ... ADD PARTITION を使用して行うのは不可能です。ただし、別の ALTER TABLE のパーティショニング関連の拡張をすることでこれを達成できます。

ALTER TABLE members REORGANIZE PARTITION p0 INTO (
    PARTITION s0 VALUES LESS THAN (1960),
    PARTITION s1 VALUES LESS THAN (1970)
);

実質的に、このコマンドはパーティション p0 を2つの新しいパーティション s0 と s1 に分けます。p0 に記憶されていたデータを2つの PARTITION ... VALUES ... 節で記されるルールによってデータが移動させられます。これにより、s0 は YEAR(dob) が1960未満の、そして s1 は YEAR(dob) 1960 以上、1970 未満のレコードを含む行が存在します。

REORGANIZE PARTITION 節を使用して隣接するパーティションを結合することができます。以下の様に members テーブルを以前のパーティションに戻すことができます。

ALTER TABLE members REORGANIZE PARTITION s0,s1 INTO (
    PARTITION p0 VALUES LESS THAN (1970)
);

REORGANIZE PARTITION を使用してパーティションを分離、結合することでデータが失われることはありません。上記のステートメントを実行する際、MySQLは s0 と s1 に記憶されていたパーティションを p0 に移動させます。

REORGANIZE PARTITION の一般的な構文は

ALTER TABLE tbl_name 
    REORGANIZE PARTITION partition_list 
    INTO (partition_definitions);

ここでは、tbl_name はパーティションドテーブルの名前で、partition_list はカンマによって分けられた、変更するべき存在するパーティションの名前です。partition_definitions はカンマによって分けられた、新しいパーティションの定義のリストで、CREATE TABLE で使用される partition_definitions リストと同様のルールに従います。(項12.1.8. 「CREATE TABLE 構文」 を参照してください)。REORGANIZE PARTITION を使用する時、複数のパーティションを１つに結合する、もしくは１つのパーティションを複数に分離することだけに制限されているわけではありません。例えば、以下の様に、members テーブル内の全4分割を2つに再編成することができます。

ALTER TABLE members REORGANIZE PARTITION p0,p1,p2,p3 INTO (
    PARTITION m0 VALUES LESS THAN (1980),
    PARTITION m1 VALUES LESS THAN (2000)
);

REORGANIZE PARTITION を LIST によってパーティションドテーブルと使用することもできます。それでは、リストによってパーティションドテーブル tt に新しいパーティションを追加する問題に戻ってみましょう。この問題は、新しいパーティションに、すでに存在するパーティションの値リストに含まれる値が新しいパーティションにも含まれていたため、失敗に終わりました。これは、衝突しない値を含むパーティションを追加することで対処し、新しいパーティションを存在するパーティションを再編成する際に、存在するパーティション内に含まれていた値が新しいパーティションに移動することで、解決できます。

ALTER TABLE tt ADD PARTITION (PARTITION np VALUES IN (4, 8));
ALTER TABLE tt REORGANIZE PARTITION p1,np INTO (
    PARTITION p1 VALUES IN (6, 18),
    PARTITION np VALUES in (4, 8, 12)
);

RANGE や LIST を使用してパーティションドテーブルを再度分割する際に使用される ALTER TABLE ... REORGANIZE PARTITION に関する重要なポイントは、以下のとおりです。

ハッシュやキーによりパーティションドテーブルは、分割セットアップ変更を行う際に手順が似ていますが、レンジやリストによりパーティションドテーブルとは、いくつかの違いがあります。そのため、このセクションはハッシュやキーのみによりパーティションドテーブルの改良を紹介します。レンジやリストによりパーティションドテーブルの追加や削除については、項15.3.1. 「RANGE と LIST パーティションの管理」 を参照してください。

HASH や KEY によりパーティションドテーブルを RANGE や LIST によりパーティションドテーブルと同じように削除することはできません。ただし、HASH や KEY 分割は ALTER TABLE ...COALESCE PARTITIONコマンドを使って結合することはできます。例えば、12のパーティションに分かれた、クライアントのデータを含むテーブルがあるとします。clients テーブルは以下の様に定義されています。

CREATE TABLE clients (
    id INT,
    fname VARCHAR(30),
    lname VARCHAR(30),
    signed DATE
)
PARTITION BY HASH( MONTH(signed) )
PARTITIONS 12;

パーティションの数を12から8に減らす場合、以下の ALTER TABLE コマンドを実行することができます。

mysql> ALTER TABLE clients COALESCE PARTITION 4;
Query OK, 0 rows affected (0.02 sec)

COALESCE は HASH, KEY、LINEAR HASH、または LINEAR KEY によりパーティションドテーブルとは同じ様に使用できます。ここに、以前の例と類似している例を記します。LINEAR KEY により分割されているという点のみ、異なります。

mysql> CREATE TABLE clients_lk (
    ->     id INT,
    ->     fname VARCHAR(30),
    ->     lname VARCHAR(30),
    ->     signed DATE
    -> )
    -> PARTITION BY LINEAR KEY(signed)
    -> PARTITIONS 12;
Query OK, 0 rows affected (0.03 sec)

mysql> ALTER TABLE clients_lk COALESCE PARTITION 4;
Query OK, 0 rows affected (0.06 sec)
Records: 0  Duplicates: 0  Warnings: 0

COALESCE PARTITION は残りの分割に結合されるパーティションの数を示しています。? 言い換えると、テーブルから取り除くパーティションの数を指します。

テーブルに含まれているいる以上の分割を取り除こうとすると、以下のようなエラーが表示されます。

mysql> ALTER TABLE clients COALESCE PARTITION 18;
ERROR 1478 (HY000): Cannot remove all partitions, use DROP TABLE instead

clients テーブル内のパーティションの数を12から18に増やす場合、ALTER TABLE ...ADD PARTITIONを、以下に示されるとおり使用してください。

ALTER TABLE clients ADD PARTITION PARTITIONS 6;

MySQL では複数のパーティショニングメンテナンスタスクを行うことができます。5.1.MySQLでは CHECK TABLE、OPTIMIZE TABLE、ANALYZE TABLE、そして REPAIR TABLEのようなコマンドをパーティションドテーブル用にサポートされてはいません。 代わりに、MySQL5.1.5で実装された ALTER TABLE の拡張子のいくつかを使用することができます。これらはこのような種類のオペレーションを直接１つ、もしくは複数の分割に実行するのに使用できます。以下のリストを参照してください。

mysqlcheck や myisamchk ユーティリティを使用してこれらのタスクを達成することができます。これらは、テーブルを分割することによって別々の .MYI ファイルに生成されています。項7.11. 「mysqlcheck ? テーブル メンテナンスと修復プログラム」 を参照してください。

このセクションでは、存在するパーティションの情報を取得するいくつかの方法を紹介します。これらは：

この章で別途紹介されているように、SHOW CREATE TABLE はその出力にパーティションドテーブルの作成に用いる PARTITION BY 節を含んでいる。例:

mysql> SHOW CREATE TABLE trb3\G
*************************** 1. row ***************************
       Table: trb3
Create Table: CREATE TABLE `trb3` (
  `id` int(11) default NULL,
  `name` varchar(50) default NULL,
  `purchased` date default NULL
) ENGINE=MyISAM DEFAULT CHARSET=latin1 
PARTITION BY RANGE (YEAR(purchased)) (
  PARTITION p0 VALUES LESS THAN (1990) ENGINE = MyISAM, 
  PARTITION p1 VALUES LESS THAN (1995) ENGINE = MyISAM, 
  PARTITION p2 VALUES LESS THAN (2000) ENGINE = MyISAM, 
  PARTITION p3 VALUES LESS THAN (2005) ENGINE = MyISAM
)
1 row in set (0.00 sec)

注:MySQL 5.1の最初のリリースでは、PARTITIONS 節は、HASH や KEY によってパーティションドテーブルでは表示されませんでした。この問題は MySQL 5.1.6. で修正されました。

SHOW TABLE STATUS はパーティションドテーブルと作動します。MySQL 5.1.9に始まり、分割されていないテーブルと出力は同じですが、Create_options カラムに partitioned 文字列を含んでいます。MySQL 5.1.8 以前では、Engine カラムには必ず PARTITION の値が含まれていました。MySQL 5.1.9 に始まり、このカラムはテーブルに使用される全ての分割のストレージエンジンの名前を含んでいます。(このコマンドの詳細については、項12.5.4.27. 「SHOW TABLE STATUS 構文」 を参照してください。）

パーティションの情報は PARTITIONS テーブルが含まれる、INFORMATION_SCHEMA からも取得できます。項21.19. 「INFORMATION_SCHEMA PARTITIONS テーブル」 を参照してください。

MySQL 5.1.5 に始まり、EXPLAIN PARTITIONS を使用して、パーティションドテーブルのどの分割がある SELECT と関係しているかを判定することができます。PARTITIONS キーワードはクエリと照合されるれレコードを記した分割をリストする、EXPLAIN のアウトプットに partitions カラムを追加します。

例えば、以下の様に定義・実装されたテーブル trb1 があるとします。

CREATE TABLE trb1 (id INT, name VARCHAR(50), purchased DATE)
    PARTITION BY RANGE(id)
    (
        PARTITION p0 VALUES LESS THAN (3),
        PARTITION p1 VALUES LESS THAN (7),
        PARTITION p2 VALUES LESS THAN (9),
        PARTITION p3 VALUES LESS THAN (11)
    );

INSERT INTO trb1 VALUES
    (1, 'desk organiser', '2003-10-15'),
    (2, 'CD player', '1993-11-05'),
    (3, 'TV set', '1996-03-10'),
    (4, 'bookcase', '1982-01-10'),
    (5, 'exercise bike', '2004-05-09'),
    (6, 'sofa', '1987-06-05'),
    (7, 'popcorn maker', '2001-11-22'),
    (8, 'aquarium', '1992-08-04'),
    (9, 'study desk', '1984-09-16'),
    (10, 'lava lamp', '1998-12-25');

以下の様に、どの分割が SELECT * FROM trb1; といったクエリで使用されているかを確認することができます。

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: trb1
   partitions: p0,p1,p2,p3
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using filesort

この場合、全4つのパーティションが検索されます。ただし、分割キーを使用して作成された制限がクエリに追加された時、以下のように、合致する値を含むパーティションのみが検索されます。

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1 WHERE id < 5\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: trb1
   partitions: p0,p1
         type: ALL
possible_keys: NULL
          key: NULL
      key_len: NULL
          ref: NULL
         rows: 10
        Extra: Using where

EXPLAIN PARTITIONS は標準的な EXPLAIN SELECT ステートメントのように、キーや可能性のあるキーに関する情報を提供します。

mysql> ALTER TABLE trb1 ADD PRIMARY KEY (id);
Query OK, 10 rows affected (0.03 sec)
Records: 10  Duplicates: 0  Warnings: 0

mysql> EXPLAIN PARTITIONS SELECT * FROM trb1 WHERE id < 5\G
*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: trb1
   partitions: p0,p1
         type: range
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 4
          ref: NULL
         rows: 7
        Extra: Using where

以下の、EXPLAIN PARTITIONS の制限や規制について注意してください。

項6.2.1. 「EXPLAINを使用して、クエリを最適化する」 も参照してください。