MySQL パーティション フィールド列に別のインデックスを作成する必要がありますか?

MySQL パーティション フィールド列に別のインデックスを作成する必要がありますか?

序文

パーティション フィールドは主キーの一部でなければならないことは誰もが知っています。では、複合主キーを作成した後、パーティション フィールドに別のインデックスを追加する必要がありますか?効果はありますか?検証してみましょう。早速、詳しい紹介を見ていきましょう。

1. 新しいテーブル effect_new を作成します (作成時間に基づいて月ごとにパーティション化されます)

テーブル `effect_new` を作成します (
 `id` bigint(20) NOT NULL AUTO_INCREMENT,
 `type` tinyint(4) NOT NULL デフォルト '0',
 `timezone` varchar(10) デフォルト NULL,
 `date` varchar(10) NOT NULL,
 `hour` varchar(2) デフォルト NULL,
 `position` varchar(200) デフォルト NULL,
 `country` varchar(32) NOT NULL,
 `create_time` 日時 NOT NULL デフォルト '1970-01-01 00:00:00',
 主キー (`id`,`create_time`)、
 キー `index_date_hour_country` (`date`,`hour`,`country`)
) ENGINE=InnoDB AUTO_INCREMENT=983041 デフォルトCHARSET=utf8
範囲によるパーティション分割 (TO_DAYS (`create_time`))
(パーティション p0 の値が (736754) 未満です) エンジン = InnoDB、
 パーティション p1 の値が (736785) 未満です。エンジン = InnoDB、
 パーティション p2 の値が (736815) 未満です。エンジン = InnoDB、
 パーティション p3 の値が (736846) 未満です。エンジン = InnoDB、
 パーティション p4 の値が (736876) 未満です。エンジン = InnoDB、
 パーティション p5 の値が (736907) 未満です。エンジン = InnoDB、
 パーティション p6 値が (736938) 未満です。エンジン = InnoDB、
 パーティション p7 の値が (736968) 未満です。エンジン = InnoDB、
 パーティション p8 値が (736999) 未満 エンジン = InnoDB、
 パーティション p9 値が (737029) 未満です。エンジン = InnoDB、
 パーティション p10 の値が (737060) 未満です。エンジン = InnoDB);

2. データを挿入します。

`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('1', '0', 'GMT+8', '2017-07-01', '', 'M-NotiCleanFull-FamilyRecom-0026', '', '2017-07-02 00:07:02') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('2', '1', 'GMT+8', '2017-09-30', '23', 'Ma5dtJub', 'EG', '2017-10-01 00:00:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('3', '1', 'GMT+8', '2017-09-10', '10', '28', 'DZ', '2017-09-11 00:08:20') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('4', '1', 'GMT+8', '2017-02-03', '20', '32', 'AD', '2017-02-04 00:00:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('5', '0', 'GMT+8', '2017-03-05', '2', NULL, 'AI', '2017-03-06 02:10:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('6', '0', 'GMT+8', '2017-09-23', '13', 'M-BrandSplash-S-0038', 'AG', '2017-09-23 13:00:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('7', '1', NULL, '2017-10-13', '12', 'BB-Main-AppAd-0018', 'AF', '2017-10-14 12:00:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('8', '0', 'GMT+8', '2017-10-28', '2', 'M-ChargeReminder-S-0040', 'AE', '2017-10-29 00:00:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('9', '1', 'GMT+8', '2017-10-09', NULL, '30', 'AI', '2017-10-10 00:09:00') に INSERT INTO します。
`effect_new` (`id`, `type`, `timezone`, `date`, `hour`, `position`, `country`, `create_time`) VALUES ('10', '0', 'GMT+8', '2017-10-05', '5', ' M-BrandSplash', 'LA', '2017-10-06 05:10:00') に INSERT INTO します。

3. ステートメントを分析する

パーティションの説明
effect_new_indexから*を選択
ここで、create_time = '2017-10-14 12:00:00'

結果は次のとおりです。

id選択タイプテーブルパーティションタイプ可能なキーキーの長さ参照フィルター余分な
1単純効果_新規8ページ全てヌルヌルヌルヌル391515 10 where の使用

4. テーブルeffect_newにインデックスidx_ctimeを追加します。

5. インデックスを追加した後の実行プランを分析する

結果は次のとおりです。

id選択タイプテーブルパーティションタイプ可能なキーキーの長さ参照フィルター余分な
1単純効果_新規8ページ参照idx_ctime idx_ctime 5定数60760 100ヌル

6. 結論:

テーブルはこのフィールドによってパーティション分割されますが、これはインデックスと同等ではありません。パーティション分割後、フィールドに特定の値を持つレコードが特定のパーティションに含まれることしか言えませんが、それはインデックスではないため、それらを見つけるのに時間がかかります。

場合によっては、主キーがパーティション列と等しくないことがあります。主キーにクラスター化インデックスを作成する場合は、パーティション列を含めて複合主キーにする必要があります。では、この場合、パーティション基準列にはインデックスがないのでしょうか?はい、しかし、十分な速度ではありません。パーティション列がこの複合インデックスで最初にランクされていない場合、十分な速度ではありません。パーティション列が検索ステートメントのフィルタリング条件として頻繁に使用される場合は、パーティション列用の追加インデックスを作成する必要があります。

要約する

上記はこの記事の全内容です。この記事にはまだ多くの欠点があります。この記事の内容が皆様の勉強や仕事に一定の参考学習価値を持つことを願っています。ご質問がある場合は、メッセージを残してコミュニケーションしてください。123WORDPRESS.COM を応援していただきありがとうございます。

以下もご興味があるかもしれません:
  • MySQL の高度な機能 - データ テーブル パーティショニングの概念とメカニズムの詳細な説明
  • MySql テーブル、データベース、シャーディング、パーティショニングの知識の詳細な説明
  • MySql テーブル、データベース、シャーディング、パーティショニングの知識ポイントの紹介
  • MySQLテーブルシャーディングとパーティショニングの具体的な実装方法
  • Navicat による MySQL パーティショニングの実践
  • MySQL パーティションテーブルの正しい使用方法
  • MySQL 最適化 Zabbix パーティション最適化
  • MySQL データベース テーブルのパーティション分割に関する考慮事項 [推奨]
  • MySQL データ テーブル パーティション テクノロジーの簡単な分析
  • MySQL データテーブルのパーティション戦略と利点と欠点の分析

<<:  VMware WorkStation 14 pro インストール Ubuntu 17.04 チュートリアル

>>:  VMware での Ubuntu と Windows 間のファイル共有

推薦する

重複リクエストを削除するAxiosのソリューションについての簡単な説明

目次1. 重複したリクエストをキャンセルする2. すべてのリクエストをクリーンアップするこのソリュー...

JavaScript 配列の include と Reduce の基本的な使用法

目次序文配列.プロトタイプ.includes文法パラメータ戻り値例配列プロトタイプの削減文法パラメー...

WeChatアプレット開発の章:落とし穴の記録

最近、会社初のミニプログラムの開発に参加しました。開発経験は基本的にWebViewをベースとしたハイ...

Dapr を使用してマイクロサービスをゼロから簡素化する例

目次序文1. Dockerをインストールする2. Dapr CLIをインストールする3. Net6 ...

MySQL 最適化ソリューション リファレンス

最適化によって発生する可能性のある問題最適化は必ずしも単純な環境で実行されるわけではなく、実稼働環境...

WeChatアプレット学習ノート: ページ構成とルーティング

最近、小さなプログラムの開発を勉強して見直しており、学習結果のいくつかをメモしています。公式の We...

Linux での fuser コマンドの使用法の詳細な説明

説明する: fuser は、現在ディスク上のファイル、マウント ポイント、さらにはネットワーク ポー...

フロントエンドの HTML 知識ポイントのまとめ (推奨)

1. HTMLの概要htyper テキスト マークアップ言語 ハイパーテキスト マークアップ言語ハ...

VUEはFlappy Birdゲームのサンプルコードを実装します

Flappy Bird は、誰もがアプリでプレイしたことがある非常にシンプルな小さなゲームです。ここ...

熟練デザイナーの7つの原則(1):フォントデザイン

まあ、あなたはデザインの達人かもしれませんし、あるいはそれは大げさすぎるかもしれませんが、少なくとも...

Dockerコンテナでルート権限を取得する方法

まず、コンテナが稼働している必要がありますコンテナのCONTAINER IDは、sudo docke...

MySQLトランザクションが効率に与える影響の分析と概要

1. データベース トランザクションによりデータベースのパフォーマンスが低下します。データの一貫性と...

Ubuntu 20.04 では、隠し録音ノイズ低減機能が有効になります (推奨)

最近、 Ubuntu 20.04でkazamを使用して録音しているときに、問題が見つかりました。シス...

VUE と Canvas を使用して Thunder Fighter タイピング ゲームを実装する方法

今日は、サンダーファイタータイピングゲームを実装します。ゲームプレイは非常に簡単です。それぞれの「敵...