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、ミニプログラムアプリの敷居の低い開発のためのフロントエンドフレームワークを詳しく解説

推薦する

Vue は PDF ファイルのオンライン プレビューを実装します (pdf.js/iframe/embed を使用)

序文現在、私はコースウェア PPT のオンライン プレビューを必要とする高品質のコースに取り組んでい...

MySQL が外部キーを作成できない理由と解決策

2 つのテーブルを関連付けるときに、外部キーを作成できませんでした。このブログから、問題は、ポイント...

CSS3を使用してボタンホバーフラッシュダイナミック特殊効果コードを実装する

CSS3 の列シリーズ属性を使用してウォーターフォールレイアウトを作成する方法を紹介しました。興味の...

XHTML CSSを使用して正式なブログを書く

ブログの正式名称は「Web log」で、中国語で「ネットワークログ」を意味します。後にブログに短縮さ...

geoip を使用して nginx で地域を制限する方法

このブログは仕事のメモです環境: nginx バージョン: nginx/1.14.0 Centos ...

CentOS7 で MySQL データベースにリモート接続できない理由と解決策

序文最近、仕事で問題が発生しました。 Centos7 システムでは MySQL にリモート接続できな...

Vue.js フロントエンドプロジェクト向け多言語ソリューションのアイデアと実践

目次1. 通常どのようなコンテンツを処理する必要があるか2. 基本的な考え方3. 具体的な実践の詳細...

MySQL <> および <=> 演算子の紹介

<> 演算子機能: 等しくないことを示します。注: 「!=」演算子と同じ機能を持ちますが...

スライドドアを実装するための CSS サンプルコード

いわゆるスライディングドアテクノロジーとは、さまざまな長さのテキストに合わせてボックスの背景を自動的...

CocosCreatorでクールなレーダーチャートを描く方法

目次序文プレビュー文章グラフィックコンポーネントプロパティ機能グリッドを描く軸角度を計算するスケール...

既存のDockerコンテナの内容を変更する方法

1. Docker psはコンテナをリストします 2. Docker cpはコンテナにファイルをコピ...

MySQL 5.7.15 のインストールと設定方法のグラフィック チュートリアル (Windows)

MySQL をインストールする必要があるため、インストール手順を以下のように記録します。 自分なり...

Zabbixリモートコマンド実行の詳細な例

目次1つ。環境二。予防三つ。例Zabbix トリガーがしきい値に達すると、アラート メッセージの送信...

エレガントなJSコードの書き方

目次変数意味があり発音しやすい変数名を使用する同じ型の変数には同じ語彙を使用する検索可能な名前を使用...

HTML テーブル マークアップ チュートリアル (15): テーブル タイトル

<br />このタグを使用すると、表のタイトルを直接追加し、タイトル テキストの配置プロ...