MySql 範囲内の検索時にインデックスが有効にならない理由の分析

MySql 範囲内の検索時にインデックスが有効にならない理由の分析

1 問題の説明

この記事では、確立された複合インデックスをソートし、レコード内の非インデックス フィールドを取得します。インデックスが有効でないことがわかります。たとえば、次のテーブルがあり、DDL ステートメントは次のとおりです。

テーブル「従業員」を作成します(
 `emp_no` int(11) NULLではない、
 `birth_date` 日付がNULLではない、
 `first_name` varchar(14) NOT NULL,
 `last_name` varchar(16) NOT NULL,
 `性別` enum('M','F') NOT NULL,
 `hire_date` 日付がNULLではない、
 `age` int(11) NOT NULL,
 主キー (`emp_no`)、
 キー `unique_birth_name` (`first_name`,`last_name`) BTREE の使用
 )ENGINE=InnoDB デフォルト文字セット=utf8;

複合インデックスはunique_birth_name (first_name,last_name)です。次の文を使用します。

説明選択
 性別
から
 従業員
注文する
 ファーストネーム、
 苗字

這里寫圖片描述

上図によると、type:all および Extra:Using filesort の場合、インデックスは有効ではありません。

実験を続行し、クエリ ステートメントをさらに書き直して範囲検索を追加します。

説明選択
 性別
から
 従業員
WHERE first_name > 'Leah'
注文する
 ファーストネーム、
 苗字

実行プランは次の図に示されています。

這里寫圖片描述

ここでの結果は最初の SQL 分析と変わりません。実験を続けてください。

SQL ステートメントを書き直します。

説明選択
 性別
から
 従業員
WHERE first_name > 'Tzvetan'
注文する
 ファーストネーム、
 苗字

這里寫圖片描述

この時点で、驚くべきことに、インデックスは機能します。

2 問題分析

この時点で、私たちは大胆な推測をします。

初めてSQL分析を実行する場合、最初のorder byの後はテーブル全体のデータがまだ取得されるため、複合インデックスに保持されている主キーに従って各性別を検索して結合すると、当然、非常に多くのリソースと時間がかかります。MySQLはそのような愚かなことはしません。テーブル全体を直接スキャンし、スキャンした各データを order by で取得した一時データと連結して、必要なデータを取得する方がよいでしょう。

上記のアイデアの正しさを検証するために、3 つの SQL ステートメントを分析します。

複合インデックスに基づく最初のSQLで取得されるデータの量は300024で、これはテーブル全体のデータです。

選択
 COUNT(名)
から
 従業員
注文する
 ファーストネーム、
 苗字

這里寫圖片描述

複合インデックスに基づいて書き換えられた 2 番目の SQL によって取得されるデータ量は159149で、これはテーブル全体のデータ量の 1/2 です。

選択
 COUNT(名)
から
 従業員
WHERE first_name > 'Leah'
注文する
 ファーストネーム、
 苗字

這里寫圖片描述

複合インデックスに基づいて書き換えられた 3 番目の SQL によって取得されるデータ量は36731で、これはテーブル全体のデータ量の 1/10 です。

選択
  COUNT(名)
から
  従業員
WHERE first_name > 'Tzvetan'
注文する
  ファーストネーム、
  苗字

這里寫圖片描述

比較すると、複合インデックスに基づいて書き換えられた 2 番目の SQL によって取得されたデータ量は、テーブル全体のデータ量の 1/2 であることがわかりました。この時点では、MySQL はまだ二次検索にインデックスを使用するレベルには達していません。複合インデックスを元に書き換えた3番目のSQLで取得するデータ量は、テーブル全体のデータ量の1/10となり、二次検索にインデックスを使ったMySQLのレベルに達しています。そのため、実行プランから書き換えた3番目のSQLはインデックスを使ったことがわかります。

3 結論

MySQL が最初のインデックス条件から照会された主キーに基づいて二次検索を実行するかどうかは、照会されたデータの量によっても異なります。データ量がテーブル全体のデータ量に近い場合は、フルテーブルスキャンが実行されます。それ以外の場合は、最初に照会された主キーに基づいて二次検索が実行されます。

これで、MySql 範囲検索中にインデックスが有効にならない問題の原因分析に関するこの記事は終了です。MySql 範囲検索中にインデックスが有効にならない問題に関する関連コンテンツの詳細については、123WORDPRESS.COM の以前の記事を検索するか、以下の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません:
  • MySQL でインデックス構造として B+ ツリーを使用する利点は何ですか?
  • MySQL データベース インデックスが B+ ツリーの使用を選択するのはなぜですか?
  • MySQL全文インデックスの原理と欠点
  • MySQL 5.6 の「暗黙的な変換」によりインデックスが失敗し、データが不正確になる
  • MySQLインデックスが失敗するいくつかの状況の詳細な分析
  • MySQL 8.0 の降順インデックス
  • MySQL 8.0 のインデックス スキップ スキャン
  • MySQL パフォーマンス最適化インデックス最適化
  • MySQL で B+ ツリー インデックスを使用する利点は何ですか?

<<:  XHTMLにおけるH1タグの位置について

>>:  iOS、Android、ミニプログラムアプリの敷居の低い開発のためのフロントエンドフレームワークを詳しく解説

推薦する

Tomcatの動作原理を分析する

SpringBoot は巨大な Python のようで、ゆっくりと私たちの周りを巻きつき、麻痺させま...

Ubuntu 20.04 は Wi-Fi に接続します (2 つの方法)

最近Ubuntu 20.04をインストールしましたが、Wi-Fiに接続できず、Wi-Fiアイコンも表...

Linux システムのパフォーマンスを分析するための top コマンドの詳細な説明

Linux topコマンドの紹介top コマンドは、Linux でよく使用されるパフォーマンス分析ツ...

Docker x509 の安全でないレジストリ問題を解決する

Docker をインストールした後、会社が構築したプライベート サーバー Harbor からプルしよ...

VMware に Linux システム (Redhat8) と仮想マシンのネットワーク構成をインストールする方法

目次1. VMwareをインストールする1.1 VMwareworkstationsをダウンロードし...

el-table のテーブルを最適化するために仮想リストを使用する方法についての簡単な説明

目次序文解決具体的な実装満たすべき前提条件質問序文テーブルをよく使用します。データ量が多い場合は直接...

MySQLのインデックス選択と最適化の詳細な説明

目次インデックスモデルB+ツリーインデックスの選択インデックスの最適化インデックスの選択性カバーイン...

Linux7で仮想ホストを実装する3つの方法

1. 同じIPアドレス、異なるポート番号仮想ホスト 1: ホスト IP アドレスは 172.16.3...

ウェブページにコンテンツが多すぎる場合に、下から上へ素早く戻る方法

Web フロントエンド開発では、ページに多くの記事を表示することが避けられません。記事の最後にあるク...

mysql57サービスが突然消えた問題をすぐに解決する

1つ、 G:\MySQL\MySQL Server 5.7\bin> mysqld --ini...

Angularデータバインディングとその実装の詳細な説明

目次序文データバインディングとは何ですか? Angular のデータバインディングの種類一方向データ...

IDEAでVUEプロジェクトをデバッグするための詳細な手順

js コードをデバッグするには、コード内にデバッガーを記述するか、Chrome で毎回ブレークポイン...

Vue の計算プロパティの紹介

目次1. 計算プロパティとは何ですか? 2. 計算プロパティの構文3. 例1. 計算プロパティとは何...

Navicat による MySQL パーティショニングの実践

MySQLのパーティショニングは、非常に大きなテーブルを管理するのに役立ちます。MySQLのパーティ...

HTTPSの最も優れた説明

皆さんおはようございます。しばらく記事を更新していませんでした。実は、私は流行中に1か月以上家にいて...