コンセプト
サブテーブルは、データ・ストレージ・エンジニアが達成するためにmysqlの基本的な機能を使用している間のパーティションは、関数MySQLの支持機構で、ちらつきのジョブの数のコンテンツもしないでください。
パーティションテーブルが2つの類似が異なる概念に分割されます。
実際には、何のサブmysqlのテーブルには、この概念が存在しない、サブテーブルは、（データの量は、一日百万が生成されます）、すなわちデータのテーブルが多すぎる、ヒトの治療に代わってエンジニアであり、それはエンジニアかもしれませんこのようにテーブルから作成された、（例えば、時間的に、例えば1日テーブルまたは月に作成されたテーブルを作成する）動作するサブテーブルを考慮し、テーブル構造は、同じであるが、異なるデータ・ストア。大まかに言えば、内容のテーブルと考えることができますが、各テーブルが別々の実体である、各テーブルには、独自のテーブルのメタデータファイル（.FRM）とテーブルスペースファイル（の.ibd）を持っている（例では、デフォルトの使用を示しあなたはMyISAMテーブルの使用に特別な要件の特定がない限り、InnoDBエンジンは、適切に言えば、）はInnoDBを使用することをお勧めします。
ゾーニングを達成するためにMySQLの内部機構である、パーティションのオペレーティング・テーブルがパーティションは、キーワードパーティションによって実行される、パーティションテーブルと呼ばれます。パーティションテーブルは、いくつかの指定されたルールに従ってパーティションを分割した後、内容のテーブルであり、データテーブルの動作がより効率的であることができるように、関連するコンテンツと一緒に格納することができます。MySQLのパーティションテーブルが内部実装され、それは論理テーブル（のみ.FRMファイル）であるが、異なる分割規則にテーブルスペースファイル（の.ibd）の複数を有していてもよく、異なる記憶するために使用データパーティション。
パーティションテーブルの原則
パーティションテーブルは、独立した論理テーブルが、物理サブ基礎となる複数のテーブル（物理サブテーブルに格納されたデータ）です。
SQLが懸念しているのでために、達成された基本となる実装パッケージ内のパーティションテーブルを呼び出し、それが透明であり、あなたはこのテーブルを操作しているが、最適化プロセスの後に、これのために手術台の基礎となる各種の通過となりますパーティション（物理子テーブル）。
MySQLの実施形態では、インデックスは、子パーティション定義テーブルに基づいているので、グローバルインデックスせずに、基礎となる表のパーティションテーブルを封入することによって実現されます。
あなたがテーブルを作成すると、各パーティションに格納されたデータを定義するために句「でパーティション」を使用。クエリを実行するときや、MySQLのオプティマイザは、クエリのニーズが照会スキャンの範囲を狭めるために必要なデータが含まれているパーティションの数は限られてスキャンするように、パーティションの定義によれば、パーティションのデータを除外する必要はありません。
パーティションテーブルのアプリケーションと利点
- テーブルは、彼らがすべてのメモリ内に配置することができない非常に大きい、またはホットデータだけテーブルの最後の部分では、他の履歴データです。
- 簡単にデータパーティションテーブルを維持するために（バッチにしたいデリートデータは道のパーティション全体をクリアするために使用することができ、また、別のパーティション上、点検、修理や他の操作を最適化することができます）。
- パーティションテーブルのデータは、異なる物理デバイス上に分散させることができます。
- パーティションテーブルは、iノードロック競合ext3ファイルシステムのような単一のインデックスのInnoDB相互排他的アクセスのようなある特定のボトルネックを回避するために使用される、などであってもよいです。
- あなたは、バックアップおよび独立したパーティションを復元することができます。
パーティションテーブルを制限します
- 表は、1024個のパーティションまで可能。
- パーティション式は、整数でなければならない、又は発現を直接カラム・パーティションを使用することも、もちろん、可能な整数を返します。
- パーティションのフィールドは、一意キーまたは主キーのインデックスでなければなりません。
- パーティションテーブルは、外部キー制約を使用することはできません。
パーティションテーブルの動作ロジック
選択クエリ
場合、クエリ・パーティション・テーブル、オープンに隔壁層及び基礎となるすべてのテーブルをロックし、オプティマイザは、入札パーティションを濾過するかどうかを決定し、各パーティションエンジンに格納されたアクセスデータに対応するインタフェースを呼び出します。
InnoDBは、ロックおよびロック解除プロセスは、一般的な問い合わせに類似しており、隔壁層に対応するテーブルロックを解除します。
挿入操作
レコードが書き込まれると、隔壁層が開き、すべての基礎となるテーブルをロックし、このレコードを受信し、対応する下にあるレコードのテーブルに書き込まれているパーティションを決定します。
削除操作
レコードが削除されると、隔壁層が開き、すべての基本となるテーブルをロックして、パーティションに対応するデータを決定し、最終的に対応する基礎となるテーブルの削除操作します。
更新操作
レコードを更新する場合、隔壁層が開き、レコードがパーティション内で更新する必要があるかを決定するために、すべての基本となるテーブルをロックし、その後、削除して、データを更新し、更新されたデータが配置されるべきパーティションを決定し、最終的に基礎となる表にします書き込み操作、および基礎となる生データテーブル削除操作。
サポートされているパーティションタイプ
MySQLのサポート範囲、ハッシュ、キー、リスト、コンポジットパーティション種々の方法、2つの一般に使用される、即ち、レンジおよびレンジ分割方法ハッシュハッシュ分割があります。
パーティション式は列にすることができ、それは列が含まれている式にすることができます。パーティション句は、様々な機能に使用することができるが、式の値は、特定の整数であることがパーティションのニーズを返し、かつ一定にすることはできません。
パーティションテーブルを作成します。
作成するために分割する日付範囲を使用してパーティションテーブルtest_partitionを
create table test_partition(
id int not null auto_increment,
name varchar(16) default '',
birth datetime,
primary key(id,birth)
)engine=innodb default charset=utf8 partition by range(year(birth))(
partition p_2016 values less than (2016),
partition p_2017 values less than (2017),
partition p_2018 values less than (2018),
partition p_catchall values less than maxvalue);test_partitionの表は、成功はどのように作成した後、私たちは、ファイルテーブルを見ることができます。
# ls -l
total 1180
-rw-r----- 1 mysql mysql 65 Nov 2 11:37 db.opt
-rw-r----- 1 mysql mysql 8618 Nov 21 10:20 test_partition.frm
-rw-r----- 1 mysql mysql 98304 Nov 21 10:20 test_partition#P#p_2016.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 10:24 test_partition#P#p_2017.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 10:20 test_partition#P#p_2018.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 10:20 test_partition#P#p_catchall.ibd前述したと同じように、である、パーティションテーブルはテーブルスペース複数のファイル（の.ibdは、識別番号を用いて分離した）、総ゲージメタデータファイル（.FRM）を有しています。
子パーティション
パーティションMySQLのパーティションテーブルには、サブパーティション・モード、即ち、パーティションテーブルパーティションパーティションをサポートします。
私たちは、作成にtest_partitionを使用して、サブパーティションテーブルtest_subpartitionが含まれているパーティションを
create table test_subpartition(
id int not null auto_increment,
name varchar(16) default '',
birth datetime,
primary key(id,birth)
)engine=innodb default charset=utf8 partition by rangenge(year(birth)) subpartition by hash(id) subpartitions 2 (
partition p_2016 values less than (2016),
partition p_2017 values less than (2017),
partition p_2018 values less than (2018),
partition p_catchall values less than maxvalue);私たちはこれを見て含まれているサブパーティションテーブルのパーティションテーブルtest_subpartitionファイルは次のようです：
# ls -l
total 1180
-rw-r----- 1 mysql mysql 65 Nov 2 11:37 db.opt
-rw-r----- 1 mysql mysql 8618 Nov 21 14:27 test_subpartition.frm
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2016#SP#p_2016sp0.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2016#SP#p_2016sp1.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2017#SP#p_2017sp0.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2017#SP#p_2017sp1.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2018#SP#p_2018sp0.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_2018#SP#p_2018sp1.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_catchall#SP#p_catchallsp0.ibd
-rw-r----- 1 mysql mysql 98304 Nov 21 14:27 test_subpartition#P#p_catchall#SP#p_catchallsp1.ibdはい、各パーティション（p_2016、p_2017、p_2018及びp_catchall）表スペース・ファイル（.idb）と2つの名前付きSP0、SP1サブテーブルスペースファイルに分割されています。
特別な事情
表インクリメント主キー列IDが中央に格納された最も近いホットスポットデータに所望の時間に応じて、存在すると仮定する。時間区分に応じて、したがって、これらの主キーと矛盾する自身の仕事や意義の主キーでタイムスタンプが含まれている必要があります。
この場合、パーティション1,000,000にデータは、両方の分割の目的を達成するように、DIV分割動作が行われる。このよう（識別DIV 1000000）において使用することができるだけでなく、しきい値に必要なパーティショニングを超えた後の時間の使用を回避新たな問題のパーティション。
クエリの最適化のパーティションテーブル
条件が列を分割する場所に持ち込まパーティション表について、オプティマイザはので、訪問することなくパーティションをフィルタリングすることができ、余分時には一見して列を分割持参してください、そうでなければ、すべてのストレージエンジンのテーブルにアクセスすることができます。表が非常に大きい場合、パーティションは、速度が非常に遅くなります。
「パーティションの説明」を使用したパーティションフィルタリングするかどうかの観測オプティマイザことができます。
MySQLは、カラム自体の分配関数の使用と比較したときにのみ、パーティションをフィルタリングすることができ、この式は、パーティション機能が動作しない場合でも、式の値に基づいてフィルタパーティションに行くことができないことに注意してください。
あなたは、パーティションを作成するときに式を使用することができますが、中にそうしても、クエリShiqueに列に基づいてパーティションのみをフィルタリングします。
