MySQLのチューニングパーティションテーブル6 ---

パーティションテーブルの原則

パーティションテーブルは、関連する複数の基礎となる表によって実装され、このテーブルは、基礎となるオブジェクトへのハンドルで識別され、我々は直接各パーティションにアクセスすることができます。一般的な管理などのストレージエンジン管理パーティションテーブル及び各テーブルの底部（基礎となるすべてのテーブルが同じストレージエンジンを使用しなければならない）、知識インデックスパーティションそれぞれの基礎となるテーブル上のテーブルに加え、同一のインデックス。ビューのストレージエンジンポイントの観点から、基礎となる表と通常の表には、異なるストレージエンジンにも、これは通常のテーブルまたはパーティションテーブルの一部である知っている必要がありません。

パーティションテーブルの動作は以下の動作ロジックに従って実行されます。

選択クエリ

パーティションテーブル、隔壁層を開いて、すべての基礎となるテーブルをロックするクエリは、オプティマイザがパーティションにフィルタリング部分か否かを判断し、ときに各エンジン・パーティションに格納されたアクセスデータに対応するインタフェースを呼び出します

挿入操作

レコードが書き込まれると、隔壁層が開き、すべての基礎となるテーブルをロックし、次に判断このレコードを受け入れるためにどのパーティション、および、対応する下にあるレコードのテーブルに書き込むために

削除操作

レコードが削除されると、隔壁層が開き、すべての基本となるテーブルをロックして、パーティションに対応するデータを決定し、最終的に対応する基礎となるテーブルの削除操作します

更新操作

記録、オープンに隔壁層を更新し、すべての基礎となるテーブルをロックすると、mysqlの最初のレコードが再パーティションする必要があり、更新されたデータ、および最終的には基礎となるテーブルを決定し、その後削除し、データを更新し、更新された後、どのパーティションを決定する、とします書き込み操作、および基礎となるデータソーステーブルの削除操作

レコードを削除するときの条件が正確にされている場合、一部の運用サポート・フィルタリングは、例えば、MySQLはどこで分割式のマッチング、パーティションが除外されているこれらのレコードのすべてが含まれていないことができ、このレコードを見つける必要があるであろう同様に効果的な更新。挿入操作は、それ自体が一つだけのパーティションをヒットした場合、他のパーティションは除外されます。MySQLは最初のパーティションテーブルと、他のパーティション上では動作しませんされたパーティションに属するレコードを決定し、その後、対応するレコードを書きます

各操作「は、すべての基礎となるテーブルを開いてロックする第一」であろうが、ストレージエンジンは、それらの行レベルのロックを達成する場合には、例えば、InnoDBのために、パーティションテーブルがプロセスにフル・テーブルをロックしていることを意味しない、一方対応表のロック解除層パーティション。

パーティションテーブルタイプ

レンジパーティショニング

行の指定された範囲内の列の値は、パーティションに割り当てされた
パーティションテーブルをレンジ・パーティション化方法である：各パーティションは、所与のパーティション内のデータ線および発現を含むパーティションの範囲は連続的ではなく重なり合うことができるべきですあなたは以下に定義演算子よりも値を使用することができます。

1、一般的なテーブルを作成します

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

2は、パーティションを指定して、文は、パーティションに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 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)
);
--在当前的建表语句中可以看到，store_id的值在1-5的在p0分区，6-10的在p1分区，11-15的在p3分区，16-20的在p4分区，但是如果插入超过20的值就会报错，因为mysql不知道将数据放在哪个分区

3、あなたはこれを回避するために、MAXVALUE未満を使用することができます

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表示始终大于等于最大可能整数值的整数值

リスト・パーティション化

同様にレンジ・パーティションのように、リストはパーティション列の値に基づいていることを除いては、選択される離散値の組に一致します

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

列のパーティション

スタートからの支援のMySQL 5.5列パーティションに、私は考えることができます5.5後範囲とリストアップグレード版では、列を分割する代替範囲やリストを使用することができますが、列のパーティションは通常の列を受け入れる式を受け入れません

 CREATE TABLE `list_c` (
 `c1` int(11) DEFAULT NULL,
 `c2` int(11) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50500 PARTITION BY RANGE COLUMNS(c1)
(PARTITION p0 VALUES LESS THAN (5) ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10) ENGINE = InnoDB) */

 CREATE TABLE `list_c` (
 `c1` int(11) DEFAULT NULL,
 `c2` int(11) DEFAULT NULL,
 `c3` char(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50500 PARTITION BY RANGE COLUMNS(c1,c3)
(PARTITION p0 VALUES LESS THAN (5,'aaa') ENGINE = InnoDB,
 PARTITION p1 VALUES LESS THAN (10,'bbb') ENGINE = InnoDB) */

 CREATE TABLE `list_c` (
 `c1` int(11) DEFAULT NULL,
 `c2` int(11) DEFAULT NULL,
 `c3` char(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
/*!50500 PARTITION BY LIST COLUMNS(c3)
(PARTITION p0 VALUES IN ('aaa') ENGINE = InnoDB,
 PARTITION p1 VALUES IN ('bbb') ENGINE = InnoDB) */

ハッシュ・パーティション化

パーティションは、ユーザ定義式の戻り値に基づいて選択され、発現は、これらの行のテーブルの列の値が計算さに挿入されるために使用されます。この関数は、負でない整数値を生成する、有効な任意の発現myqlを含むことができ

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

キーパーティション

それは唯一のパーティションキーの1つ以上の列をサポートし、独自のMySQLサーバハッシュ関数を提供する以外はハッシュ・パーティションは、1つ以上の列が整数値を含むがなければならない、類似しています

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

子パーティション

上のパーティションに基づいて、その後、パーティション貯蔵後

CREATE TABLE `t_partition_by_subpart`
(
  `id` INT AUTO_INCREMENT,
  `sName` VARCHAR(10) NOT NULL,
  `sAge` INT(2) UNSIGNED ZEROFILL NOT NULL,
  `sAddr` VARCHAR(20) DEFAULT NULL,
  `sGrade` INT(2) NOT NULL,
  `sStuId` INT(8) DEFAULT NULL,
  `sSex` INT(1) UNSIGNED DEFAULT NULL,
  PRIMARY KEY (`id`, `sGrade`)
)  ENGINE = INNODB
PARTITION BY RANGE(id)
SUBPARTITION BY HASH(sGrade) SUBPARTITIONS 2
(
PARTITION p0 VALUES LESS THAN(5),
PARTITION p1 VALUES LESS THAN(10),
PARTITION p2 VALUES LESS THAN(15)
);

パーティションテーブルの制限

1. Aの表は、8196パーティションをサポートすることができたときに、バージョン5.7で、1024のパーティションの最大を持つことができる
でmysql5.5で、初期のMySQLでは2を、パーティションは整数式または整数を返す式でなければなりませんいくつかのシナリオは、直接列分割するために使用することができます
ユニークなプライマリキーまたはインデックス・パーティションフィールドがある場合、すべての主キー列と列が来るように一意のインデックスを含んでいなければならない3.
4.パーティションテーブルの外部キー制約を使用することはできません

使い方

ビッグデータの分割（偶数インデックスを使用して、あなたは残骸の多くを生成するだけでなく、ランダムIOの多くが生成されますでしょう）
ゾーニング規則に従ってストアテーブルにはなく、任意のインデックスへの単純1.パーティショニングは、一般的に必要なデータまで配置します条件は、パーティションの少数に限られているデータを使用する必要がどこに、このポリシーがアクセスする通常の方法に大量のデータを適用し
、することができます。2.データが明らかにホットスポットがある場合に、データのこの部分に加えて、他のデータはほとんどアクセスされていませんデータがインデックスを使用することができ、クエリはわずかなパーティションテーブルにアクセスできるように、メモリにキャッシュしている機会を持つことができるように別のパーティション上のホット・データのこの部分、パーティションは、効果的にキャッシュを使用することが可能です

シナリオ

1.テーブルは、彼らがすべてのメモリに配置することができない、または唯一のテーブルの最後の部分ではホットデータは、他の過去のデータであることを非常に大きい
2.データパーティションテーブルは、保守が容易です。データの一括削除大量道のパーティション全体をクリアするために使用することができ、最適化の点検、修理などの操作に別のパーティションに。
3.パーティションテーブルデータは、効率的なハードウェア装置を複数利用し、異なる物理デバイス上に分散させることができる
。4.パーティションテーブルは、特定の特別なボトルネックを防止するために使用することができます。InnoDBは、単一のインデックスへの排他的アクセス; iノードロックext3ファイルシステムの競争。
バックアップと復元は別のパーティションすることができ

問題への注意

ヌル値が無効なパーティションフィルタします
パーティション列と索引列が一致しない、クエリがフィルタパーティションにつながることはありません
選択したパーティションはコストがかかる（パーティションは、ファイルを保存するには、ストレージスペースの多くを取るでしょう）
、基礎となるすべてを開いてロックしますコストテーブルは高いかもしれない
（あなたは新しいパーティションを作成し、古いパーティションを削除したいパーティション変更）メンテナンスコストが高い分配することができ