パーティションテーブルの歴史
1は、MySQL 5.1のバージョンが整数列に基づいて、パーティションテーブルをサポートするために始めた 2、MySQLの5.5バージョンは、TRUNCATEのパーティションをサポートし、RANGEとLISTパーティションをサポートするために始めた、新しいパーティションCOLUMNSが簡略化の定義をキーワード。 図3は、MySQLは5.6バージョンでは、スワップパーティション、パーティションのサポート明示的なクエリをサポートし始めた8182のパーティションまたはサブパーティションをサポートします。 4、MySQLの5.7バージョンは、ローカルパーティション化戦略を紹介し、放棄された共通の分割戦略をマークします。
パーティショニング戦略
オープンパーティション管理行動のパーティショニング戦略は2つのカテゴリに分類することができますによると： 1、ユニバーサル・パーティション化戦略（ジェネリックパーティショニング）、MySQLサーバ層は、パーティションへのアクセスを制御する役割を担います。 2、ローカル分割戦略（ネイティブパーティション）、ストレージエンジン層パーティションへのアクセスを制御する役割を担います。 MySQLはMySQLサーバー層の実装にパーティションテーブル、パーティションテーブルへのアクセス制御操作をサポートし始めたとき、より粗い結果として、パフォーマンス、文書管理/テーブル管理の面で深刻な問題があります。異なる層は、インデックス/アクセス制御（ロック）の異なるストレージエンジン記憶機構/構造を使用し、増強または特殊設計により動作特定最適化することができ、パーティションは、アクセス制御ポリシーストレージエンジン良好に配置されます。 一般的なパーティション化戦略の問題： 1、パーティションテーブルが最初にアクセスされ、関係なく、パーティションを操作するのに必要なアクセス数の、あなたはパフォーマンスの問題を引き起こして、パーティションテーブルの上のすべてのパーティションにアクセスする必要があります。おそらくパラメータopen_file_limit制限とエラーを超えて開いているファイルの数のパーティション表のパーティションの場合は多数。 101を区画する隔壁100から延長されるように、元のファイルと新しいファイルのパーティション、パーティションテーブルを維持しつつ、パーティションテーブルがパーティションによって維持することができる場合に2は、100に+ 2 * 2 * 101 = 402のファイル記述子を必要とします。 MySQLの5.7.9バージョンでは、パーティションテーブルの動作によってローカル分割戦略、内部管理アクセスInnoDBストレージエンジン層のInnoDBの導入。 MySQLの5.7.17のリリースでは、MySQLは非推奨のような一般的なパーティション化戦略がマークされているだろう 、もはやのMyISAMエンジンは、ローカルパーティション化戦略をサポートしていないので、MyISAMのエンジンパーティションテーブルを使用することを許可のMySQL 8.0バージョンに。 現在、2つだけのストレージエンジンはInnoDBとNDBのサポートローカルパーティション化戦略。
MySQLの5.7パーティショニング機能の強化
MySQLの5.7パーティショニング機能の強化： 1、MySQLの5.7.1は、HANDLERステートメントのサポートを開始した（非標準のSQL文を、インデックスを指定してデータにアクセスするためのDML操作をサポートしていない、オプティマイザがSQLのオーバーヘッドを解析し、最適化減らし、クエリのパフォーマンスを向上させる。） 2、 MySQLの5.7.2開始サブパーティションのサポートは/ CHECK / OPTIMIZE / REPAIR / ANALYZE TRUNCATE 操作 3、MySQL5.7.3支持指標条件プッシュダウン（ICP）特性を 図4に示すように、InnoDBのテーブルパーティションのエクスポートオプションとしてMySQL 5.7.4サポートFLUSHテーブル 5、サポートパフォーマンスを向上させるためにキャッシュを使用してデータをロードし、各パーティションは、130キロバイトのバッファ使用 6を、パーティションテーブルのサポートのMyISAMインデックスキャッシュに対するキャッシュINTOステートメントキャッシュ指標と荷重指数の使用をサポートしています
パーティションテーブルの利点
MySQLではサーバ層パーティションテーブルがパーティションテーブルのMySQLストレージエンジン層は、複数のテーブルであり、従って、以下の特徴を有するテーブルである： 1、サービスの透明性のパーティションテーブルのみテーブルのデータ構造を維持する必要があります。 2、DML操作のロックが唯一のパーティションに影響を与え、未訪問のパーティションの操作には影響を与えません。 3、データはすぐにパーティションのパーティションテーブル交換を通じて内外にスワップ。 図4は、迅速TRUNCATE操作することにより、特定のパーティションのデータをクリーンアップします。 5、パーティションを強制することにより、特定のデータパーティションへのアクセスは縮小操作に影響を与えます。 図6に示すように、データ・パーティションの多量によって効果的にクエリパフォーマンスを向上させるために、インデックスの層の数を減らすことができます。
パーティションテーブルの欠点
MySQLサーバ層でのパーティションテーブルはこのようにテーブル、ですので、： 1は、DDL操作は結果の操作は、すべてのパーティション上でブロックされている、すべてのパーティションをロックする必要があります。 図2に示すように、データテーブル、パーティションテーブルと非パーティションテーブル類似の性質の少量、パーティションテーブルの効果は限られています。 大きなデータテーブルの量、パーティションテーブル又は他の高いDDL動作およびメンテナンス作業が困難で危険である3、。 4、単一のサーバは、パフォーマンス、分割パーティションテーブルの高コストを満たすことができません。 5、パーティションテーブルが少なく使用するには、複数の、マルチBUGバグBUGと、より多くの、MySQLコミュニティ版無料、低コストの規模、シンプルかつ完璧なミドルウェアサブライブラリーサブテーブル実装の未知の危険性があります。