MySQL 5.1.12 より、以下の生成子はパーティショニング表現で許可されていません。

MySQL 5.1.12 より、以下特定の MySQL 関数はパーティショニング表現で許容されていません。

+、–、×、そして / といった数的演算子はパーティショニング表現で許容されています。ただし、結果は整数値もしくは NULL でなければいけません。 ([LINEAR] KEY パーティショニングは例外となります。— 詳細については項15.2. 「パーティショニングのタイプ」 を参照してください)。

MySQL 5.1.12 にはじまり、|、&、^, <<、>> そして ~ といったビット演算子はパーティショニング表現では許容されていません。

MySQL 5.1.12 より、以下特定の MySQL 関数のみがパーティショニング表現で許容されています。

重要サーバ SQL モード次第で、いくつもの MySQL 関数や演算子の結果が変更される可能性に注意してください。このため、パーティショニングされたテーブルを作成したあとモードを変更することは推奨できません。項4.2.6. 「SQL モード」 を参照してください。

ASCII() や ORD() といった関数を使用して文字列を(たとえば CHAR あるいは VARCHAR カラム)整数に変換するのは、文字列が8-ビットキャラクタセットを使用している時のみ可能です。文字列に使用される照合順序は関連キャラクタセットのどの照合順序でも可能です。ただし、latin1_german2_ci、latin2_czech_cs、そして cp1250_czech_cs などの照合順序は1対複数の変換を擁するため、使用は不可能です。

パーティションの最大数は 1024 になります。これはサブパーティションを含めた値です。

もし、多くのパーティションを使用してテーブルを作成する場合（しかし上記の最大数よりも少ない場合）、以下のエラーメッセージが発生します。Got error 24 from storage engine これは、open_files_limit システム変数の値を増加させなければいけないという意味です。項B.1.2.17. 「'File' Not Found and Similar Errors」 を参照してください。

パーティショニングされたテーブルは外部キーをサポートしません。これは、InnoDBストレージエンジンを使用しているテーブルも含みます。

パーティショニングされたテーブルは FULLTEXT をサポートしません。これは、MyISAM ストレージエンジンを使用しているテーブルも含みます。

パーティショニングされたテーブルは GEOMETRY カラムをサポートしません。

MySQL 5.1.8 以降、テンポラリテーブルはパーティショニングできません。（Bug#17497)

MERGE ストレージ エンジンを使用しているテーブルはパーティショニングできません。

FEDERATED テーブルのパーティショニングはサポートされていません。MySQL 5.1.15 からは、パーティショニングされた FEDERATED テーブルを作成する事は不可能になりました。将来的に、この制限をMySQLから取り除く方向で開発を進めています。

CSV ストレージ エンジンを使ったパーティショニングはサポートされません。MySQL 5.1.12 からは、パーティショニングされた CSV テーブルを作成する事は不可能になりました。

MySQL 5.1.6 以前では、BLACKHOLE ストレージエンジンを使用しているテーブルはパーティショニング不可能でした。

KEY (あるいは LINEAR KEY)によるパーティショニングが、NDB ストレージエンジンでサポートされる唯一のパーティショニングです。MySQL 5.1.12 で始まり、[LINEAR] KEY以外のパーティショニングのタイプを使用してクラスタテーブルを作成するのが不可能になりました。実行するとエラーが発生します。

アップグレードを実行中 KEY によりパーティショニングされ、NDBCLUSTER 以外のストレージエンジンを使用しているテーブルは、いったんダンプしてからリストアする必要があります。

テーブルのパーティションとサブパーティションすべてが(後者の場合、存在していれば)同じストレージ エンジンを使用していなければいけません。将来的に、この制限をMySQLから取り除く方向で開発を進めています。

パーティショニングキーは整数カラム、もしくは整数に帰結する表現でなければいけません。カラム、もしくは表現値は NULL となりえます。（詳しくは 項15.2.6. 「MySQLパーティショニングの NULL 値の取り扱い」 をご確認ください。）

この規制にたいする唯一の例外は[LINEAR] KEY — を 使用してパーティショニングする際に発生します。この時、パーティショニングキーとして他タイプのカラムを使用することができるのは、— MySQL の内部キーハッシュ関数はこれらの型から正しいデータ型を生成するからです。例えば、以下の CREATE TABLE ステートメントは有効です。

CREATE TABLE tkc (c1 CHAR)
PARTITION BY KEY(c1)
PARTITIONS 4;

この例外は BLOB や TEXT カラム型に 適用されません。

サブクエリが整数値もしくは NULL に帰結するとしても、サブクエリをパーティショニングキーとして利用することは出来ません。

パーティショニングされたテーブルのパーティショニング表現に使用される全てのカラムはテーブル内に存在する全てのユニークキーの一部でなければいけない。.言い換えると、テーブル内のユニークキー全てはテーブルパーティショニング表現の全てのカラムを使用しなければいけない。たとえば、以下のテーブル作成ステートメントは無効です。

CREATE TABLE t1 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1, col2)
)
PARTITION BY HASH(col3)
PARTITIONS 4;

CREATE TABLE t2 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1),
    UNIQUE KEY (col3)
)
PARTITION BY HASH(col1 + col3)
PARTITIONS 4;

CREATE TABLE t3 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1, col2),
    UNIQUE KEY (col3)
)
PARTITION BY HASH(col1 + col3)
PARTITIONS 4;

各ケースで、挙げられたテーブルはパーティショニング表現で使用されているカラム全てを含まないユニークキーを、１つは保持していることになります。.

以下の各ステートメントは有効であり、対応する無効なテーブル作成ステートメントを有効とする方法を１つ現しています。

CREATE TABLE t1 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1, col2, col3)
)
PARTITION BY HASH(col3)
PARTITIONS 4;

CREATE TABLE t2 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1, col3)
)
PARTITION BY HASH(col1 + col3)
PARTITIONS 4;

CREATE TABLE t3 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    UNIQUE KEY (col1, col2, col3),
    UNIQUE KEY (col3)
)
PARTITION BY HASH(col3)
PARTITIONS 4;

各プライマリキーは定義によるとユニークキーなので、この規制は、テーブルにそれが含まれる場合、テーブルのプライマリキーに対しても働きます。例えば、下記の2ステートメントは無効です

CREATE TABLE t4 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    PRIMARY KEY(col1, col2)
)
PARTITION BY HASH(col3)
PARTITIONS 4;

CREATE TABLE t5 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    PRIMARY KEY(col1, col3),
    UNIQUE KEY(col2)
)
PARTITION BY HASH( YEAR(col2) )
PARTITIONS 4;

両ケースの場合、プライマリキーはパーティショニング表現で参照される全てのカラムを含んではいません。ただし、以下の2ステートメントは有効です。

CREATE TABLE t6 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    PRIMARY KEY(col1, col2)
)
PARTITION BY HASH(col1 + YEAR(col2))
PARTITIONS 4;

CREATE TABLE t7 (
    col1 INT NOT NULL,
    col2 DATE NOT NULL,
    col3 INT NOT NULL,
    col4 INT NOT NULL,
    PRIMARY KEY(col1, col2, col4),
    UNIQUE KEY(col2, col1)
)
PARTITION BY HASH(col1 + YEAR(col2))
PARTITIONS 4;

テーブルにユニークキーがない場合、— これはプライマリキーが内場合も含む — この規制は適用されません。カラム型がパーティショニングのタイプと適合している限り、パーティショニング表現内のどのカラムも使用することが可能です。

同じ理由で、後からパーティショニングされたテーブルにユニークキーを追加することはできません。ただし、テーブルのパーティショニング表現内に含まれる全カラムがキーに含まれている場合、これは可能となります。以下にパーティショニングされたテーブルの定義が記されているとします。

CREATE TABLE t_no_pk (c1 INT, c2 INT) 
    PARTITION BY RANGE(c1) (
        PARTITION p0 VALUES LESS THAN (10), 
        PARTITION p1 VALUES LESS THAN (20), 
        PARTITION p2 VALUES LESS THAN (30), 
        PARTITION p3 VALUES LESS THAN (40)
    );

次の ALTER TABLE ステートメントのどちらかを使用して、t_no_pk にプライマリキーを付け加えることができます。

#  possible PK
ALTER TABLE t_no_pk ADD PRIMARY KEY(c1);

#  also a possible PK
ALTER TABLE t_no_pk ADD PRIMARY KEY(c1, c2);

ただし、次のステートメントは失敗します。なぜなら、c1 はパーティショニングキーの一部であっても、プライマリキーの一部ではないからです。

#  fails with ERROR 1482
ALTER TABLE t_no_pk ADD PRIMARY KEY(c2);

t_no_pk はパーティショニング表現に c1 しかないため、c2 にのみユニークキーを追加使用としても、失敗に終わります。ただし、c1 と c2 を両方使用するユニークキーを追加することは可能です。

これらのルールは、ALTER TABLE ... PARTITION BY を使用してパーティショニングしたいテーブルにも適用されます。以下 np_pk と定義されたテーブルを検討してください。

CREATE TABLE np_pk (
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    added DATE,
    PRIMARY KEY (id)
);

続く ALTER TABLE ステートメントはエラーで失敗します。これは added カラムがテーブル内のユニークキーの一部ではないからです。

ALTER TABLE np_pk
    PARTITION BY HASH( TO_DAYS(added) )
    PARTITIONS 4;

このステートメントは、有効になります。

ALTER TABLE np_pk
    PARTITION BY HASH(id)
    PARTITIONS 4;

np_pk の場合、パーティショニング表現の一部として使用できるカラムは id になります。パーティショニング表現内の他のカラムを使用してこのテーブルをパーティショニングしたい場合、まず必要なカラムをプライマリキーに追加するか、プライマリキー自体を破棄することでテーブルを改良しなければいけません。

将来的に、この制限をMySQLから取り除く方向で開発を進めています。

サブパーティショニングは HASH や KEY パーティショニングに限定されます。HASH や KEY パーティショニングに対してサブパーティショニングを行うことはできません。