序文：
MySQL 5.6 以前のバージョンでは、クエリ オプティマイザーはブラック ボックスのようなもので、EXPLAINオプティマイザーがステートメントを通じて使用することを決定した実行プランを表示することしかできませんが、オプティマイザーがこの決定を行った理由を知ることはできません。これは、真相を解明したい一部の友人にとっては災難です。「他の実行スキームを使用する方が、出力EXPLAINスキームよりも優れていると感じます。なぜオプティマイザは、私が考えているのと異なる決定を下すのでしょうか?」この記事では、主にoptimizer trace、ビュー オプティマイザーを使用して実行計画を生成するプロセス全体
オプティマイザ トレース テーブルの魔法
MySQL 5.6 以降のバージョンでは、MySQL を設計したおじさんが、optimizer traceこうした小さなパートナー向けに、思慮深く、オプティマイザが実行計画を生成するプロセス全体を簡単に表示できる機能を提案しました。この機能のオープンは、シャットダウンに関連しています。システム変数によって決定されるのでoptimizer_trace、見てみましょう。
mysql> show variables like 'optimizer_trace';
+-----------------+--------------------------+
| Variable_name | Value |
+-----------------+--------------------------+
| optimizer_trace | enabled=off,one_line=off |
+-----------------+--------------------------+
1 row in set (0.01 sec)
enabled値 が表示されoff、この機能がデフォルトで無効になっていることを示します。
小提示：
one_lineの値は出力形式を制御します。これを に設定すると、onすべての出力が 1 行で表示され、人間が読むのには適さないため、デフォルト値のオフのままにします。
この機能を有効にしたい場合は、まず次のように、enabled の値を on に変更する必要があります。
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.00 sec)
次に、最適化プロセスを表示するクエリ ステートメントを入力します。クエリ ステートメントが実行されると、information_schemaデータベースの下のOPTIMIZER_TRACEテーブルで完全な最適化プロセスを表示できます。このOPTIMIZER_TRACEテーブルには次の 4 つの列があります。
QUERY: クエリ文を示します。TRACE: 最適化プロセスを表す JSON 形式のテキスト。MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 最適化処理により大量に出力される場合があるため、一定の制限を超えると冗長テキストが表示されなくなり、無視されたテキストのバイト数が表示されます。INSUFFICIENT_PRIVILEGES: 最適化プロセスを表示する権限がないかどうかを示します。デフォルト値は 0 ですが、特別な場合にのみ 1 になります。当面は、このフィールドの値は気にしません。
オプティマイザー トレース機能を使用するための完全な手順は、次のように要約されます。
ステップ 1:オプティマイザー トレース機能をオンにします (デフォルトではオフになっています)。
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.01 sec)
ステップ 2:ここに独自のクエリを入力します
SELECT ...;
ステップ 3: OPTIMIZER_TRACE テーブルから前のクエリの最適化プロセスを表示する
SELECT * FROM information_schema.OPTIMIZER_TRACE;
ステップ 4:他のステートメント実行の最適化プロセスを観察する必要がある場合もあります。上記のステップ 2 と 3 を繰り返します。
ステップ 5:ステートメントの最適化プロセスの表示を停止するときは、オプティマイザー トレース機能をオフにします。
mysql> SET optimizer_trace="enabled=off";
Query OK, 0 rows affected (0.01 sec)
これで、多くの検索条件を含むクエリ ステートメントができました。その実行計画は次のとおりです。
mysql> EXPLAIN SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc';
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
| 1 | SIMPLE | s1 | NULL | range | idx_key2,idx_key1,idx_key3 | idx_key1 | 403 | NULL | 1 | 5.00 | Using index condition; Using where |
+----+-------------+-------+------------+-------+----------------------------+----------+---------+------+------+----------+------------------------------------+
1 row in set, 1 warning (0.00 sec)
このクエリで使用できるインデックスが 3 つあることがわかりますが、オプティマイザはなぜ最終的にidx_key1他のインデックスや直接フル テーブル スキャンの代わりに選択したのでしょうか? 現時点では、otpimzer trace関数を使用してオプティマイザーの特定の作業プロセスを表示できます。
mysql> SET optimizer_trace="enabled=on";
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc';
Empty set (0.00 sec)
mysql> SELECT * FROM information_schema.OPTIMIZER_TRACE\G
OPTIMIZER_TRACEクエリ テーブルを通じて取得された出力を直接見てみましょう(#最適化プロセスのより重要なポイントのいくつかを、コメントの形で説明し、その後それを使用して説明しました。注意してください)。
*************************** 1. row ***************************
# 分析的查询语句是什么
QUERY: SELECT * FROM s1 WHERE key1 > 'z' AND key2 < 1000000 AND key3 IN ('aa', 'bb', 'cb') AND common_field = 'abc'
# 优化的具体过程
TRACE: {
"steps": [
{
"join_preparation": { # prepare阶段
"select#": 1,
"steps": [
{
"IN_uses_bisection": true
},
{
"expanded_query": "/* select#1 */ select `s1`.`id` AS `id`,`s1`.`key1` AS `key1`,`s1`.`key2` AS `key2`,`s1`.`key3` AS `key3`,`s1`.`key_part1` AS `key_part1`,`s1`.`key_part2` AS `key_part2`,`s1`.`key_part3` AS `key_part3`,`s1`.`common_field` AS `common_field` from `s1` where ((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and (`s1`.`common_field` = 'abc'))"
}
]
}
},
{
"join_optimization": { # optimize阶段
"select#": 1,
"steps": [
{
"condition_processing": { # 处理搜索条件
"condition": "WHERE",
# 原始搜索条件
"original_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and (`s1`.`common_field` = 'abc'))",
"steps": [
{
# 等值传递转换
"transformation": "equality_propagation",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
},
{
# 常量传递转换
"transformation": "constant_propagation",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
},
{
# 去除没用的条件
"transformation": "trivial_condition_removal",
"resulting_condition": "((`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')) and multiple equal('abc', `s1`.`common_field`))"
}
]
}
},
{
# 替换虚拟生成列
"substitute_generated_columns": {
}
},
{
# 表的依赖信息
"table_dependencies": [
{
"table": "`s1`",
"row_may_be_null": false,
"map_bit": 0,
"depends_on_map_bits": [
]
}
]
},
{
"ref_optimizer_key_uses": [
]
},
{
# 预估不同单表访问方法的访问成本
"rows_estimation": [
{
"table": "`s1`",
"range_analysis": {
"table_scan": {
"rows": 20250,
"cost": 2051.35
},
# 分析可能使用的索引
"potential_range_indexes": [
{
"index": "PRIMARY", # 主键不可用
"usable": false,
"cause": "not_applicable"
},
{
"index": "idx_key2",# idx_key2可能被使用
"usable": true,
"key_parts": [
"key2"
]
},
{
"index": "idx_key1", # idx_key1可能被使用
"usable": true,
"key_parts": [
"key1",
"id"
]
},
{
"index": "idx_key3", # idx_key3可能被使用
"usable": true,
"key_parts": [
"key3",
"id"
]
},
{
"index": "idx_key_part", # idx_key_part不可用
"usable": false,
"cause": "not_applicable"
}
],
"setup_range_conditions": [
],
"group_index_range": {
"chosen": false,
"cause": "not_group_by_or_distinct"
},
"skip_scan_range": {
"potential_skip_scan_indexes": [
{
"index": "idx_key2",
"usable": false,
"cause": "query_references_nonkey_column"
},
{
"index": "idx_key1",
"usable": false,
"cause": "query_references_nonkey_column"
},
{
"index": "idx_key3",
"usable": false,
"cause": "query_references_nonkey_column"
}
]
},
# 分析各种可能使用的索引的成本
"analyzing_range_alternatives": {
"range_scan_alternatives": [
{
# 使用idx_key2的成本分析
"index": "idx_key2",
# 使用idx_key2的范围区间
"ranges": [
"NULL < key2 < 1000000"
],
"index_dives_for_eq_ranges": true,# 是否使用index dive
"rowid_ordered": false,# 使用该索引获取的记录是否按照主键排序
"using_mrr": false, # 是否使用mrr
"index_only": false, # 是否是索引覆盖访问
"in_memory": 1,
"rows": 10125,# 使用该索引获取的记录条数
"cost": 3544.01,# 使用该索引的成本
"chosen": false, # 使用该索引的成本
"cause": "cost" # 因为成本太大所以不选择该索引
},
{
# 使用idx_key1的成本分析
"index": "idx_key1",
# 使用idx_key1的范围区间
"ranges": [
"'z' < key1"
],
"index_dives_for_eq_ranges": true,# 同上
"rowid_ordered": false,# 同上
"using_mrr": false,# 同上
"index_only": false,# 同上
"in_memory": 1,
"rows": 1,# 同上
"cost": 0.61,# 同上
"chosen": true# 是否选择该索引
},
{
# 使用idx_key3的成本分析
"index": "idx_key3",
# 使用idx_key3的范围区间
"ranges": [
"key3 = 'aa'",
"key3 = 'bb'",
"key3 = 'cb'"
],
"index_dives_for_eq_ranges": true,# 同上
"rowid_ordered": false,# 同上
"using_mrr": false,# 同上
"index_only": false,# 同上
"in_memory": 1,
"rows": 3,# 同上
"cost": 1.81,# 同上
"chosen": false,# 同上
"cause": "cost"# 同上
}
],
# 分析使用索引合并的成本
"analyzing_roworder_intersect": {
"usable": false,
"cause": "too_few_roworder_scans"
}
},
# 对于上述单表查询s1最优的访问方法
"chosen_range_access_summary": {
"range_access_plan": {
"type": "range_scan",
"index": "idx_key1",
"rows": 1,
"ranges": [
"'z' < key1"
]
},
"rows_for_plan": 1,
"cost_for_plan": 0.61,
"chosen": true
}
}
}
]
},
{
# 分析各种可能的执行计划
#（对多表查询这可能有很多种不同的方案，单表查询的方案上边已经分析过了，直接选取idx_key1就好）
"considered_execution_plans": [
{
"plan_prefix": [
],
"table": "`s1`",
"best_access_path": {
"considered_access_paths": [
{
"rows_to_scan": 1,
"access_type": "range",
"range_details": {
"used_index": "idx_key1"
},
"resulting_rows": 1,
"cost": 0.71,
"chosen": true
}
]
},
"condition_filtering_pct": 100,
"rows_for_plan": 1,
"cost_for_plan": 0.71,
"chosen": true
}
]
},
{
"attaching_conditions_to_tables": {
"original_condition": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))",
"attached_conditions_computation": [
],
"attached_conditions_summary": [
{
"table": "`s1`",
"attached": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
}
},
{
# 尝试给查询添加一些其他的查询条件
"finalizing_table_conditions": [
{
"table": "`s1`",
"original_table_condition": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))",
"final_table_condition ": "((`s1`.`common_field` = 'abc') and (`s1`.`key1` > 'z') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
},
{
# 再稍稍的改进一下执行计划
"refine_plan": [
{
"table": "`s1`",
"pushed_index_condition": "(`s1`.`key1` > 'z')",
"table_condition_attached": "((`s1`.`common_field` = 'abc') and (`s1`.`key2` < 1000000) and (`s1`.`key3` in ('aa','bb','cb')))"
}
]
}
]
}
},
{
"join_execution": { # execute阶段
"select#": 1,
"steps": [
]
}
}
]
}
# 因优化过程文本太多而丢弃的文本字节大小，值为0时表示并没有丢弃
MISSING_BYTES_BEYOND_MAX_MEM_SIZE: 0
# 权限字段
INSUFFICIENT_PRIVILEGES: 0
1 row in set (0.01 sec)
ERROR:
No query specified
この出力を見ると、最初の印象は、このテキストが多すぎるということです。実際、これはオプティマイザ実行プロセスのほんの一部にすぎません。MySQL の今後のバージョンでは、さらに最適化プロセス情報が追加される可能性があります。しかし、実際にはカオスは非常に規則的であり、最適化プロセスは大きく 3 つの段階に分かれています。
- 準備段階
- ステージを最適化する
- 実行ステージ
私たちが話しているコストベースの最適化は主にoptimizeステージ に焦点を当てています。単一テーブル クエリの場合は、主にoptimizeステージ のこのプロセスに焦点を当て"rows_estimation"ます。このプロセスは、単一テーブル クエリのさまざまな実行スキームのコストを深く分析します。複数テーブルの場合は、結合クエリ 一般に、"considered_execution_plans"さまざまな接続方法に対応するコストを説明するこのプロセスには、より注意を払う必要があります。いずれにしても、オプティマイザは最終的にコストが最も低い計画を最終的な実行計画として選択します。これは、EXPLAINステートメントを使用して示す種類の計画です。
EXPLAINステートメントで表示される特定のクエリの実行計画が理解できない友人がいる場合は、optimizer traceこの機能を使用して各実行計画に対応するコストを詳しく知ることができ、MySQL クエリについてより深く理解できると思います。 .オプティマイザー。
今日の勉強はこれで終わりです、あなたが壊れない自分になれることを願っています
~~~
先を見据えて点と点を結ぶことはできません。過去を振り返って接続することしかできません。したがって、点と点が何らかの形であなたの将来につながると信じなければなりません。あなたは何かを信頼しなければなりません - 自分の直感、運命、人生、カルマ、何でも。このアプローチは私を決して失望させず、私の人生に大きな変化をもたらしました
私のコンテンツがあなたのお役に立てましたら、どうぞ点赞、、、創作は簡単ではありません、皆さんのサポートが私が頑張れる原動力です评论收藏
