mysqlチューニング4パーティションテーブル
記事のディレクトリ
序文
この記事では、パーティションテーブルを使用してmysqlを最適化する方法について説明します。
1.パーティションテーブルの原理
1.パーティションテーブルの構成：
パーティションテーブルは、関連する複数の基になるテーブルによって実装され、各パーティションに直接アクセスできます。ストレージエンジンは、基礎となる各テーブルのパーティションを管理し、通常のテーブルを管理します（基礎となるすべてのテーブルは、同じストレージエンジンを使用する必要があります）。パーティションテーブルのインデックスは、基礎となる各テーブルに同一のインデックスを追加するだけです。
2.パーティションテーブル操作ロジック：
SELECT：
パーティションテーブルをクエリすると、パーティションレイヤーが開き、基になるすべてのテーブルをロックします。オプティマイザーは、最初に一部のパーティションをフィルター処理できるかどうかを判断し、次に対応するストレージエンジンインターフェイスを呼び出して、のデータにアクセスします。各パーティション。
挿入：
レコードを書き込むとき、パーティションレイヤーはすべての基になるテーブルを開いてロックし、最初にどのパーティションがレコードを受け取るかを決定してから、対応する基になるテーブルにレコードを書き込みます。
削除：
レコードを削除する場合、パーティションレイヤーはすべての基になるテーブルを開いてロックし、最初にデータに対応するパーティションを決定してから、対応する基になるテーブルを削除します。
更新：
レコードを更新するとき、パーティションレイヤーは、基になるすべてのテーブルを開いてロックします。最初に、レコードを更新する必要があるパーティションを特定し、データをフェッチして更新し、次に、更新されたデータをどのパーティションに含めるかを決定し、最後に書き込みます。基になるテーブルに移動し、ソースデータが配置されている基になるテーブルを削除します。
注：関連する操作の場合、where条件がパーティション式（つまり、パーティション条件）と一致する場合、他のパーティション操作なしで、レコードを含まないすべてのパーティションをフィルターで除外できます。
ストレージエンジンがInnoDBの場合、パーティションレイヤーで対応するテーブルロックを解放し、それを行ロックに変換します（InnoDBは行レベルのロックを実装できるため）。
2つ目は、パーティションテーブルタイプです。
1.範囲パーティション
列の値に応じて、対応する行が指定された範囲内の対応するパーティションに割り当てられます。各パーティションには行データが含まれ、パーティションの式は指定された範囲内にあります。パーティションの範囲は連続している必要があり、重複することはできません。演算子未満の値を使用して定義できます。
CREATE TABLE useremp (
id INT NOT NULL,
name VARCHAR(30),
creat_date DATE NOT NULL DEFAULT '1970-01-01',
code INT NOT NULL,
user_id INT NOT NULL
)
-- 根据user_id创建四个分区，maxvalue表示始终大于等于最大可能整数值的整数值
PARTITION BY RANGE (user_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
);
-- 根据creat_date创建分区（精确年）
PARTITION BY RANGE ( YEAR(create_date) ) (
PARTITION p0 VALUES LESS THAN (1991),
PARTITION p1 VALUES LESS THAN (1996),
PARTITION p2 VALUES LESS THAN (2001),
PARTITION p3 VALUES LESS THAN MAXVALUE
);
-- 根据creat_date创建分区（精确天）
PARTITION BY RANGE COLUMNS(create_date) (
PARTITION p0 VALUES LESS THAN ('1960-01-01'),
PARTITION p1 VALUES LESS THAN ('1970-01-01'),
PARTITION p2 VALUES LESS THAN ('1980-01-01'),
PARTITION p3 VALUES LESS THAN ('1990-01-01'),
PARTITION p4 VALUES LESS THAN MAXVALUE
);
2.リストパーティション
範囲分割と同様に、リスト分割は、分割を選択するために設定された離散値の値と一致する列値に基づいています。
PARTITION BY LIST(user_id) (
PARTITION p1 VALUES IN (3,5,6,9,17),
PARTITION p2 VALUES IN (1,2,10,11,19,20),
PARTITION p3 VALUES IN (4,12,13,14,18),
PARTITION p4 VALUES IN (7,8,15,16)
);
3.列パーティション
5.5以降、列分割がサポートされます。これは、範囲分割とリスト分割のアップグレードバージョンと見なすことができます。列分割は通常の列のみを受け入れ、式は受け入れません。
CREATE TABLE test_list (
col1 int(11) DEFAULT NULL,
col2 int(11) DEFAULT NULL,
col3 char(20) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=latin1
PARTITION BY RANGE COLUMNS(col1,col3)
(PARTITION p0 VALUES LESS THAN (10,'aaa') ENGINE = InnoDB,
PARTITION p1 VALUES LESS THAN (20,'bbb') ENGINE = InnoDB);
4.ハッシュパーティション
選択されたパーティションは、テーブルに挿入されるこれらの行の列値を使用して計算されるユーザー定義式の戻り値に基づいています。
CREATE TABLE useremp2 (
id INT NOT NULL,
name VARCHAR(30),
code INT NOT NULL,
creat_date DATE NOT NULL DEFAULT '1970-01-01',
user_id INT NOT NULL
)
-- 对user_id取hash值%4产生四个分区
PARTITION BY HASH(user_id)
PARTITIONS 4;
-- 对creat_date的年份取hash值%4产生四个分区
PARTITION BY LINEAR HASH(YEAR(creat_date))
PARTITIONS 4;
5.キーパーティション
ハッシュパーティショニングと同様に、キーパーティショニングは1つ以上の列をサポートし、mysqlサーバーは独自のハッシュ関数を提供し、1つ以上の列には整数値が含まれている必要があるという違いがあります。
6.サブパーティション
パーティション分割に基づいて、パーティション分割後のストレージ。
CREATE TABLE test_table
(
id INT AUTO_INCREMENT,
name VARCHAR(10) NOT NULL,
status INT(2) NOT NULL
PRIMARY KEY (id, status)
) ENGINE = INNODB
PARTITION BY RANGE(id)
SUBPARTITION BY HASH(status) SUBPARTITIONS 2
(
PARTITION p0 VALUES LESS THAN(5),
PARTITION p1 VALUES LESS THAN(10),
PARTITION p2 VALUES LESS THAN(15)
);
3、パーティションテーブルの制限
1.テーブルは最大で1024パーティションしか持つことができず、バージョン5.7以降は8196パーティションをサポートできます。
2.下位バージョンでは、パーティション式は整数または整数を返す式である必要があります。5.5以降では、列を直接使用してパーティション化できます。
3.パーティションフィールドに主キーまたは一意のインデックス列がある場合は、すべての主キー列と一意のインデックス列を含める必要があります。この問題は、複合主キーを使用するか、主キーインデックスを通常のインデックスに変更することで解決できます。
4.パーティションテーブルは外部キー制約を使用できません。
第4に、アプリケーションシナリオとパーティションテーブルの利点
利点：
1。パーティションテーブルのデータをさまざまな物理デバイスに分散できるため、複数のハードウェアデバイスを効率的に使用できます。
2.パーティションテーブルのデータの保守が簡単です。大量のデータをバッチで削除するには、パーティション全体をクリアする方法を使用して、独立したパーティションを最適化、チェック、および修復できます。
3.独立したパーティションをバックアップおよび復元できます。
4.パーティションテーブルを使用して、特定のボトルネックを回避できます。InnoDBの単一インデックス相互排他アクセス
アプリケーション：
1。テーブルが大きすぎてすべてをメモリに格納できないか、テーブルの最後の部分にのみホットデータがあります。およびその他すべて履歴データです。
テーブル内のデータ量が膨大な場合、クエリを実行するたびにテーブル全体をスキャンすることは確かに不可能です。インデックスはスペースとメンテナンスを消費するため、インデックスを使用しないことをお勧めします。インデックスを使用しても、大量の断片化が発生し、大量のランダムIOが生成されます。データ量が巨大な場合、インデックスは明らかに効果的ではありません。パーティションテーブルを使用できる場合。
単純なパーティション化方法を使用して、インデックスなしでテーブルを格納し、パーティション化ルールに従って必要なデータを大まかに見つけ、where条件を使用して必要なデータをいくつかのパーティションに制限します。この方法は、大量のデータにアクセスするのに適しています。通常の方法で。
ホットスポットデータ以外のデータにホットスポットがある場合、他のデータにアクセスすることはめったにありません。ホットスポットデータのこの部分を別のパーティションに配置して、このパーティションのデータをメモリにキャッシュできるようにすることができます。クエリが小さなアクセスのみにアクセスできるように、パーティションテーブルはインデックスとキャッシュを効果的に使用できます。
注意すべき5つのポイント
1. null値はパーティションフィルターを無効にし、パーティション条件のフィールドにnull値がないことを保証する必要があります。
2.パーティション列とインデックス列が一致しないため、クエリでパーティションフィルタリングを実行できません。
3.基礎となるすべてのテーブルを開いてロックするコストは高くなる可能性があり、パーティションを維持するコストを考慮する必要があります。
総括する
適切なシナリオでパーティションテーブルを使用し、特定のビジネスシナリオに従ってパーティション分割に使用する列を決定し、メンテナンスコストやその他の問題のために必要のない場合はパーティションテーブルを使用しないでください。