情報技術の急速な発展に伴い、データ量が増大し、大規模なテーブルクエリ操作に多くの時間がかかることが、データベースアクセスのパフォーマンス向上に影響を与える主な要因となっています。データベース操作のクエリ効率とユーザー エクスペリエンスを向上させるために、リレーショナル データベース管理システム (MySQL) でレンジ パーティションとマージ ストレージを通じて最適化されたパーティション テーブル アルゴリズムが提案されています。この実験により、最適化されたアルゴリズムにより、大量のデータを扱うテーブルクエリ操作を実現する際の作業効率が大幅に向上することが証明されました。
目次
4 Merge ストレージ エンジンを使用して MySQL サブテーブル設計を実装する
4 Merge ストレージ エンジンを使用して MySQL サブテーブル設計を実装する
データ テーブル内の自己インクリメント フィールドについては、データの重複を避けるために、システムの設計時にトリガーを使用してテーブルを完成させます。マージ クエリがサブテーブルによって設計されると、クエリ速度は大きなテーブルよりもはるかに速くなり、データ クエリの効率が大幅に向上します。
4.1 テストテーブルの作成
まず、3 つのテスト テーブルpayment_2021、payment_2022、payment_all を作成します。payment_all は、最初の 2 つのテーブルのマージ テーブル (メイン テーブル) です。
create tablepayment_2021
(id smallint auto_increment 主キー、payment_date datetime、amount decmal(13，2))engine = myisam 文字セット gbk;
create tablepayment_all
(id smallint AUTO_INCREMENT PRIMARYKEY 主キー、payment_date datetime、amount decmal(13，2)) エンジン = マージ Union = (payment_2021、
payment_2022) insert_method = last;
4.2 レコードの挿入
テスト データをpayment_2021 テーブルとpayment_2022 テーブルにそれぞれ追加します。
支払い_2021(支払い_日付、金額)に挿入値(＇2021 －01 － 30＇、200 000)、(2、＇2021 － 06 －30＇、230 000)、(3、＇2021 －11 －20＇、260 000 );
支払い_2022(支払い日、金額)に挿入値(＇2022 －02 －15＇、160 000)、(＇2022 －06 －28＇、210 000)、(＇2022 －12 －20＇、220 000。 5);
図 4 に示すように、payment_all テーブルのレコードを表示します。
レコードを挿入するプロセスで、ID の重複が発生し、削除と変更の例外が発生します。解決するには、payment_all の ID に一意の値を割り当て、
初期データを挿入し、payment_2021 とpayment_2022 のデータを削除します。
SQL 过程如下：
テーブルpayment_id(id smallint)を作成します。
Payment_id 値に挿入(1);
Payment_2021 から削除;
Payment_2022 から削除;
Payment_2021 テーブルとpayment_2022 テーブルにトリガーを作成します。トリガーの機能は、payment_2021 テーブルまたはpayment_2022 テーブルにレコードを追加するときに、payment_id の ID 値を取り出し、それをpayment_2021 とpayment_2022 に割り当て、tb_ids に 1 を追加します。 ID 値。
次のようにトリガー ステートメントを作成します。
各行のpayment_2021に挿入する前に トリガtr_seq1を作成し
、payment_id制限1から@ tb_idsにIDを選択し始めます。
Payment_id セット ID = @ tb_ids +1 を更新します。
新しく設定します。id = @ tb_ids; 各行のpayment_2022に挿入する前に トリガtr_seq2を作成
終了開始 payment_id制限1から@ tb_idsにIDを選択します。 Payment_id セット ID = @ tb_ids +1 を更新します。 新しく設定します。id = @ tb_ids; 終わり
Payment_2021 テーブルとpayment_2022 テーブルにそれぞれレコードを追加します。
支払い_2021(支払い日、金額)に値(＇2021 －02 －10＇，280 000);
支払い_2022(支払い日、金額)に値(＇2022 －06 －15＇，230 000);
図 5 は、トリガーを追加した後のpayment_all テーブルのレコードを示しています。
3 つのレコードを、payment_2021 テーブルとpayment_2022 テーブルにそれぞれ追加します。
支払い_2021(支払い_日付、金額)に挿入値(＇2021 － 01 － 01＇、160 000)、(＇2021 － 05－30＇、190 000)、(＇2021 －12 －20＇、260 000);
支払い_2022(支払い日、金額)に挿入値(＇2022 － 02 － 01＇、150 000)、(＇2022 － 06－01＇、290 000)、(＇2022 －12 －25＇、220 000);
クエリを検証した後、ID は繰り返されず、トリガーは正常に作成されます。
4.3 サブテーブルを分割してサブテーブルを実現する
システム設計の過程では、業務量の増加に伴い、データテーブルのデータ量が急増します。必要なデータを迅速にクエリするために、
サブテーブルを分割することでデータの負荷を軽減し、クエリ効率を高めます。
SQLの手順は以下の通りです。
1) 従業員テーブルの作成
テーブルメンバーを作成します(member_id bigint auto_increment 主キー、member_name varchar(20)、member_sex tinyint not null デフォルト 0) エンジン = myisam デフォルト charset = utf8 auto _increment =1;
2) 500 万件のレコードを追加するストアド プロシージャを作成する
createdefiner = `root`@`localhost`procedure`member_insert`()
begindeclareiintdefault0;
while i <5 000 000 do
insert into member(member_name，member_sex)values
(concat(＇工号＇，i)，0);
i = i +1 を設定します。
途中で終了します。
自動コミット =1 を設定します。
終わり;
3) 従業員テーブルのレコードをクエリする
メンバーから count(* ) を選択します。
4) 従業員 1 テーブルを作成する
テーブルを作成します member1(member_id bigint auto_increment 主キー、member_name varchar(20)、member_sex tinyint not null デフォルト 0) エンジン = myisam デフォルト charset = utf8 auto _increment =1;
同様に、従業員 2 テーブルを作成します。
5) 従業員テーブルを 2 つのテーブルに分割します。
従業員テーブルは、ID のパリティ番号によって従業員 1 テーブルと従業員 2 テーブルに分割されます。
メンバー 1(メンバー ID、メンバー名、メンバーの性別) メンバー ID%2 =0 のメンバーからメンバー ID、メンバー名、メンバーの性別を選択; メンバー 2(メンバー ID、メンバー名、メンバーの性別) メンバー ID%2 =1 のメンバーからメンバー ID、メンバー名、メンバーの性別を
選択;
6) 従業員 1 テーブルの最初の 100,000 レコードをクエリします。
select * from member1 制限 100,000;
上記のクエリ文を実行すると、テーブルの分割が成功したことがわかります。
5。結論
データベースにおける大規模データクエリの効率を向上させ、MySQL クエリの信頼性と安定性を実現するために、大規模データクエリのプロセスにおけるパーティション特性を分析することで、従来のテーブル設計手法の欠点を見つけ出し、2 つの方法を提案します。パーティションとサブテーブルはこのベースのアルゴリズムに基づいて作成されます。高速パーティショニングとサブテーブルはレンジ パーティショニングとマージ ストレージを通じて設計されており、低速なクエリ操作を効果的に回避し、クエリ効率を向上させます。
実験結果は、提案された最適化されたパーティションテーブル設計アルゴリズムが効果的であり、分散展開が最適化され、データボリューム制御がより細かくなり、データメンテナンスが容易であることを示しています。ビジネス量の増加に伴い、テーブル分割設計には複雑な設計とクラスタ管理が必要となり、パーティションテーブル分割設計アルゴリズムをさらに洗練する必要があります。