《MySQL ： MySQL》 原価構成について問い合せます.
1.I/Oコスト 2.CPUコスト 3.Mysqlでは、ページの読み取りにかかるコストのデフォルトは1.0であり、レコードが検索条件に合致するかどうかを読み取り、検出するコストのデフォルトは0.2であることが規定されています.1.0、0.2これらの数字を原価定数と呼ぶ.
4.なお、記録の読み取り時に検索条件を満たすか否かを検出する必要がなくても、そのコストは0.2とする. 単一テーブルクエリのコスト
コストベースの最適化手順
1.単一テーブルのクエリ文が実際に実行される前に、MySQLのクエリ・オプティマイザは、その文を実行するために使用可能なすべてのシナリオを特定し、比較して最もコストの低いシナリオを特定します.この最もコストの低いシナリオは、いわゆる実行計画です.
2.具体的な流れは以下の通りである: 3.検索条件に基づいて、使用可能なすべてのインデックスを検索します.
4.全テーブルスキャンの代価を計算する 5.異なるインデックスを使用してクエリーを実行するコストを計算します.
6.様々な実行スキームの代価を比較して、最もコストの低いを見つけます.
検索条件に基づいて、使用可能なすべてのインデックスを見つけます.
1.クエリーで使用可能なインデックスをpossible keysと呼びます. 全テーブルスキャンのコストの計算
1.クラスタインデックスのページ数 2.このテーブルのレコード数 3.MySQLはテーブルごとに一連の統計情報を維持しており、上記の1と2の情報はここにあります. 4.SHOW TABLE STATUS LIKE tableNameでを検索できます.
5.Rowsはレコードを表します--innodbの下ではただの概数です. 6.Data_length--テーブルに使用されるストレージ領域のバイト数を示します. 7.Data_length=クラスタインデックスのページ数xページあたりのサイズ(16 KB) 8.I/Oコスト==ページ数*1.0+1.1 9.CPUコスト=ROWS*0.2+1.0--0.2は、1つのレコードにアクセスするために必要なコスト定数を指す.
10.総コスト=I/Oコスト+CPUコスト. 11.表のレコードはクラスタインデックス対応B+ツリーのリーフノードに格納されていると前述したので、ルートノードで一番左のリーフノードを取得すれば、リーフノードからなる双方向チェーンテーブルに沿ってすべてのレコードを表示することができます.すなわち、全テーブルスキャンというプロセスにおいて、実際にあるB+ツリー内ノードはアクセスする必要がない.上記の計算は全表スキャンで比較的粗い計算です. 異なるインデックスを使用してクエリーを実行するコストの計算
1.これらのインデックスを単独で使用してクエリーを実行するコストを個別に分析するには、最後にインデックスマージに使用できるかどうかを分析します.
2.MySQLクエリー・オプティマイザは、一意の2次インデックスを使用するコストを分析し、通常のインデックスを使用するコストを分析します.もちろん、プライマリ・キー・インデックスを直接実行することはできません. 3.二次インデックス+リターンテーブル方式を使用するクエリー:主に範囲区間数とリターンテーブルが必要なレコード数を考慮します. 4.範囲区間数:ある範囲区間の2次インデックスがどれだけのページを占有するかにかかわらず、クエリー・オプティマイザは、インデックスを読み取る範囲区間のI/Oコストと、1ページを読み取るのとが同じであると乱暴に考えている.
5.リターンテーブルが必要な記録数:まず左右の区間で定数範囲で臨界点記録を見つけることができる.そして、区間最左記録からチェーンテーブル方向に沿って区間最右記録に向かう限り.両者が10ページ以上離れていない場合は、リターンテーブルの正確なデータが得られます.それ以上の場合は10ページを集計し、各ページに含まれるレコード数を平均し、ページ数を乗算します. 6.ページ数を探して、記録しても親層が探せばいいです. 7.CPUコストは、主に2次インデックス記録を読み取るコスト+表に戻ったクラスタインデックス記録を読み出して検出するコストである.
index dive
1.Mysqlは、インデックスに対応するB+ツリーに直接アクセスすることによって、ある範囲区間に対応するインデックスレコードの本数を計算する方式をindex dive と呼ぶ.
2.2次インデックスinを使用する場合、一意ではないため、inの各パラメータにはindex dive が必要です.
3.mysql通過eq_range_index_dive_limitパラメータは,inであればパラメータ数がこのパラメータより大きい場合にインデックス統計データを用いて記録数を推定する. 4.主にROWSとCardinalityを使用し、両者は1つの繰り返し値==1つの値の繰り返し回数≒Rows÷Cardinality を計算することができる.
5.したがって、1 inの1つのパラメータは、10個のレコードを表す.
mysqlがインデックスの統計
1.MySQLは、テーブル内のインデックスごとに統計データを維持します.SHOW INDEX FROM TABLENAME 2.重要な属性:Cardinality,Sub_part 3.Cardinality:インデックス列に重複しない値の個数を表します.これは推定値です.値が大きいほど、カラムの重複値が少なくなります.値が大きいほど繰り返しが小さくなると、分割可能度が大きくなり、インデックスを確立する意味は大きくありません. 4.Sub_part:文字列またはバイト列を格納する列では、これらの列の最初のn文字またはバイトにインデックスを作成したい場合があります.この属性は、そのn値を表します.完全なカラムにインデックスを設定すると、そのプロパティの値はNULLになります. 接続クエリのコスト
1.MySQLの接続クエリーはネストされたループ接続アルゴリズムを採用しており、ドライバテーブルは一度にアクセスされ、ドライバテーブルは複数回にわたってにアクセスされる可能性があります.
2.クエリは、主に、単一のクエリ・ドライバ・テーブルのコストと複数のクエリ・ドライバ・テーブルのコスト(ドライバ・テーブル・クエリの結果セットにレコードが何個あるかによって異なるクエリの回数)のです.
3.ドライバテーブルがクエリーするレコードの数をドライバテーブルの扇出(英語名:fanout)と呼ぶ.
Condition filtering
1.全テーブルスキャン方式で実行される単一テーブルクエリーを使用する場合、駆動テーブルのセクタを計算する際に、検索条件を満たすレコードがどれだけあるかを推測する必要があります. 2.インデックス実行の単一テーブルスキャンを使用している場合は、駆動テーブルのセクタを計算する際に、対応するインデックスを使用する検索条件以外の検索条件を満たすレコードが何個あるかを推測する必要があります. 2つのテーブル接続のコスト分析
1.接続クエリの総コスト=シングルアクセスドライバテーブルのコスト+ドライバテーブルの扇出数xシングルアクセスドライバテーブルのコスト.
2.左(外)接続クエリーと右(外)接続クエリーでは、ドライバテーブルが固定されているため、最適なクエリースキームを得るには、ドライバテーブルと被ドライバテーブルのそれぞれに最もコストの低いアクセス方法を選択する必要があります. 3.内部接続については、駆動テーブルと被駆動テーブルとの位置が入れ替わるので、最適な方法を算出して実行する. マルチテーブル接続のコスト分析
1.n個のテーブルが接続されていますが、MySQLクエリーオプティマイザは接続順序ごとのコストを計算しますか? 2.最小原価値を事前に維持し、各接続順序で原価計算を問合せた場合、これより大きい場合は直接スキップします. 3.システム変数optimizer_search_depthは、最大何種類のクエリー方式を貧乏に挙げるかを規定することができます. 4.いくつかの規則に基づいて、いくつかの接続順序を考慮しません.これらの規則は啓発規則と呼ばれ、システム変数optimizer_prune_levelは、これらの啓発的なルールを使用するかどうかを制御します. せいぎょげんかていすう
1.ページの読み取りにかかるコストのデフォルトは1.0 です.
2.レコードが検索条件に合致するかどうかを測定するコストのデフォルトは0.2です.
3.実はこの2つのコスト定数のほかに、MySQLは多くのことをサポートしています.mysqlデータベースの2つのテーブルに格納されています.engine_costとserver_cost . 4.1つの文の実行は、serverレイヤ、ストレージエンジンレイヤの2つのレイヤに分かれています.
5.定数をupdateで修正し、FLUSH OPTIMIZER_でCOSTS;有効