2019年度若手技術者向け講座実行計画

概要
• 実行計画とは何か学習します。
• 実行計画の取得方法・読み方について学習し、パフォーマンス
の問題の調査方法に役立てます。
2

目次
• SQL実行までの処理の流れ
• 実行計画
• テーブルフルスキャン
• インデックススキャン
• インデックスオンリースキャン
• 結合について
• 結合の実行計画
• 結合のアルゴリズム（Nested Loops, Hash, Merge Join）
• 演習問題
• 統計情報
• 参考資料
• Oracleの実行計画
3

環境（VMへの接続）
• VM（仮想マシン）の中にPostgreSQL（バージョン11）の環境が構築
されています。
• VirtualBoxを起動し、「axis_db」のVMを起動してください。
• Tera Term(MacOSの場合はターミナル)を起動してください。
ssh接続で、ポート番号「2222」ユーザー名とパスワード「axiz」でロ
グインします。
4

環境（PostgreSQLへの接続）
• ログインできたら、下記のコマンドで「axizdb_explain」に接続して
ください。
5
# psql –U axiz –d axizdb_explain

SQL実行までの処理の流れ
6

オプティマイザ
• 処理の流れ
7
①パーサ
②プラン生成 ③コスト評価
⑤プラン評価
④カタログ
マネージャ
クエリ
パース済みのクエリ
実行計画

• パーサ
• パーサは、受け取ったSQL文のパース（構文解析）を行います。
• 受け取ったSQLが文法的に間違っていないかをチェックします。一般
的なプログラミング言語のコンパイル時に行われるものと同様です。
• また、受け取ったSQL文を一度バラバラに分解して、それをDBMSが処
理しやすい形式に変換します。
8

• オプティマイザ
• オプティマイズとは、「最適化」という意味です。
• オプティマイザは、発行されたSQL文の最適なデータアクセスの方法
を決定する部分になります。
• 選択可能な実行計画を作成し、その中から最もコストが低い計画を絞
り込みます。
9

• カタログマネージャ
• カタログマネージャは、オプティマイザが実行計画を立てる際に必要
となる重要な情報を提供します。
• DBMSは、テーブルの「統計情報」やインデックスに関する情報を持っ
ています。それらを管理する部分です。
• 一度に大量のデータを更新した場合は、統計情報も更新しないと実行
計画に影響がでる可能性があります。
• PostgerSQLの場合、ANALYZEコマンドにより最新の統計情報を更新でき
ます。
10

• プラン評価
• オプティマイザが複数の実行計画を立てた後、それを受け取って、最
適な実行計画を選択するのがプラン評価です。
• 実行計画が一つに絞り込まれた後、DBMSは実行計画を実行可能なコー
ドに変換してデータへアクセスします。
11

実行計画
• 実行計画とは
・実行計画とは、データアクセス方法のことです。
・DBMSは、SQLが発行されると、まずはそのSQL文の構文があっ
ているかをチェックします。（パーサ）
・その後、オプティマイザと呼ばれる最適化のためのソフト
ウェアが実行計画を生成します。
13

実行計画
• 実行計画の確認方法
• コマンドで実行する場合は、DBMSによって異なります。
• このテキストではPostgreSQLの環境で検証していきます。
14
DBMS コマンド
Oracle SET AUTOTRACE TRACEONLY
SQL Server SET SHOWPLAN_TEXT ON
DB2 EXPLAIN ALL WITH SNAPSHOT FOR SQL文
PostgreSQL EXPLAIN [ANALYZE] SQL文
MySQL EXPLAIN EXTENDED SQL文

実行計画
• 実行計画で使用するテーブル定義
• 今回の検証で使用するのは以下の3つのテーブルです。
• tableAとtableBはそれぞれ10万件ずつのレコードが存在します。
15
tableA インデックス
物理名型 primary key 1 a_id
a_id integer 〇
name varchar(50)
value real
tableB インデックス
物理名型 primary key 1 b_id
b_id integer 〇 2 a_id
a_id integer
value real

実行計画
• 実行計画で使用するテーブル定義
• tableCは1万件のレコードが存在し、blood_typeは4種類の値が均等に
セットされています。
16
tableC
物理名型 primary key 備考
c_id integer 〇
blood_type varchar(2) A,B,O,ABのいずれか
インデックス
1 blood_type

実行計画
• 実行計画の例
• 以下はPostgreSQLの実行計画の例です。
17

実行計画
• 実行計画の例
• SQLのツールでも実行計画の確認が可能です。
• A5M2ツールの場合は、確認したいSQLを入力した状態で「Ctrl + E」を
実行すると確認可能です。
• A5M2ツールでの確認結果
18

実行計画
• ここでは、以下の5つの実行計画を確認していきます。
• ビットマップスキャン
• テーブルの結合
• Nested loops
• Hash
• Sort Merge
19

テーブルフルスキャン
• postgresqlに接続し、実際に実行計画を見てみます。
• 以下のコマンドを実行してみましょう。
20
axizdb_explain=> EXPLAIN SELECT * FROM tableA;

• 出力された実行計画を確認してみます。
• Seq Scanはテーブルへのアクセス方法を示しており、テーブル
フルスキャンが実行されています。
• 括弧の中は、SQLの実行にかかるコスト、出力される行数、出
力されるバイト数が表示されます。
21

• テーブルフルスキャンは、対象のテーブルに対する全てのレコードを
読み込みます。
• PostgreSQLの場合は「Seq Scan」
• レコード数の多いテーブルに対してテーブルフルスキャンが行われて
いた場合パフォーマンスを低下させる可能性が高いです。
22

EXPLAIN ANALYZE
• SQL文は同じですが、続いては以下のコマンドを実行してみま
しょう。
23
axizdb_explain=> EXPLAIN ANALYZE SELECT * FROM tableA;

EXPLAIN ANALYZE
• 出力された結果を確認してみます。
• 先ほどよりも多くの情報が出力されています。
24

EXPLAIN ANALYZE
• 実行計画を確認するには「EXPLAIN <SQL文>」としますが、
「EXPLAIN ANALYZE <SQL文>」とすると、実際にSQL文を実行し、実際
にかかった時間やコストも出力されます。
• 更新系のSQL文に対して実行すると、実際にデータが更新されますの
で、使用には注意してください。
25

インデックススキャン
• 次はWHERE句を使用して条件の絞り込みをしたSQLの場合を見
てみます。
26
axizdb_explain=> EXPLAIN SELECT * FROM tableA WHERE a_id = 1;

• テーブルへのアクセス方法がIndex Scan になり、インデックス
が使用されているのが分かります。
• Index Scan using <インデックス名> on <テーブル名>
27

• インデックススキャンでは、一旦インデックスを使用して対象のレ
コードを絞り込み、対象のレコードのみを取得します。
• テーブルフルスキャンよりもディスクへのアクセス回数を減らすこと
ができるため、高いパフォーマンスが期待できます。
• テーブルに対してインデックスが複数存在する場合は、期待したイン
デックスが使用されているかどうかも確認しましょう。
28

インデックスオンリースキャン
• 次は先ほどのSQLからSELECT句で取得するカラムを一つにしま
す。
29
axizdb_explain=> EXPLAIN SELECT a_id FROM tableA WHERE a_id = 1;

• テーブルへのアクセス方法がIndex Only Scan になっています。
• 先ほどと違うのは、SELECT句に指定したカラムをa_idのみにし
ていることです。これはインデックスに含まれているカラムな
ので、インデックスのみのアクセスでデータを取得することが
できます。
30

• SELECT句に指定したカラムがインデックスに含まれる項目のみの場合
はインデックスオンリースキャンによるアクセスになることがありま
す。
• レコードにはアクセスせず、インデックスのみのアクセスでデータを
取得できるため、高いパフォーマンスが期待できます。
• SELECT句で指定するカラムが限られるので、使用される頻度は少ない
です。
31

ビットマップスキャン
• 続いて以下のコマンドを実行してみましょう。
32
axizdb_explain=> EXPLAIN SELECT * FROM tableC WHERE blood_type='A';

• テーブルへのアクセス方法がBitmap Heap Scan になっています。
• tableCでは10000件のレコードが存在するのに対し、blood_typeは
「A」「B」「O」「AB」の4パターンしか存在しません。
33

• ビットマップスキャン
• 絞り込み条件で指定したカラムのカーディナリティ（取りうる値の種
類）が少ない場合、B-Treeインデックスを使用しても効果は薄いです。
• このような場合はビットマップインデックスが使用される場合があり
ます。
• PostgreSQLの場合、実行時にメモリ上にビットマップを作成し、その
ビットマップからレコードの検索を行います。
• ただし、確認した限りWindows版のPostgreSQLにはビットマップスキャ
ンは実装されていません。
34

実行計画まとめ
• 実行計画まとめ
• テーブルへのアクセス方法は、テーブルフルスキャン、インデックス
スキャン、インデックスオンリースキャンなどがある。
• パフォーマンスが悪いときは、実行計画を確認し、テーブルへのアク
セス方法を確認する。
• レコード件数の多いテーブルに対してフルスキャンが行われている場
合は要注意。
• テーブルフルスキャンによってパフォーマンスが低下している場合は、
インデックスが使用されるようなSQL文、またはインデックス設計を
検討する。
35

実行計画まとめ
• 実行計画まとめ
• 実行計画の確認方法や表示のされ方は、DBMS製品によって異なります。
詳しくは各DBMSのマニュアル等を参照してください。
• どのDBMSであっても、実行計画で重要なのは「インデックスの使用の
有無」と「どのインデックスが使用されているか」です。
36

結合の実行計画
• 結合の実行計画
• SQLでパフォーマンスが悪いとき、結合の処理が影響している可能性
が高いです。
• 結合では主に３つのアルゴリズムが使用されます。
38

結合のアルゴリズム
• 結合のアルゴリズム
結合のアルゴリズムは、DBMSによってサポートされているものが異な
りますが、よく使用されているのは次の3つです。
• Nested Loops
• Hash
• Sort Marge
どれが使用されるかはオプティマイザが判断します。
一つ一つ確認していきましょう。
39

Nested Loops
• まずは以下のSQL文の実行計画を確認します。
• 実行結果は2レコードになるSQL文になっています。
40
axizdb_explain=> EXPLAIN SELECT * FROM tableA a
INNER JOIN tableB b
ON a.a_id = b.a_id
WHERE b.value = 1
AND b.a_id BETWEEN 10 AND 200;

Nested Loops
• 実行計画を確認してみます。
• Nested Loop表示されているのが分かります。
• Nested Loopsのアルゴリズムで結合が行われています。
41

Nested Loops
• Nested Loops
• Nested Loopsが結合の最もメジャーなアルゴリズムです。
• このようなSQL文を実行するとき、取得するレコードが少ない方の
テーブルを「駆動表」といいます。
• 「駆動表」でない方のテーブルを「内部表」といいます。
42
SELECT * FROM table1
INNER JOIN table2
ON table1.column = table2.column

Nested Loops
• Nested Loopsのアルゴリズム
• 駆動表を1行ずつループしながらスキャンする。
• 駆動表の1行に対して、内部表を1行ずるスキャンして、結合条件に合
致する場合はそれを取得する。
• その処理を駆動表のすべてのループに対して実施。
結合の処理を速くなる条件は
• 「駆動表を小さくする」
• 「内部表の結合キーにインデックスが存在する」
の2つがポイントになります。
43

Hash
• 先ほどのSQLから少し条件を変更してみます。
• 今回は実行結果は1000レコード出力されます。
44
INNER JOIN tableB b
ON a.a_id = b.a_id
WHERE b.value = 1;

Hash
• Hash Joinと表示されているのが分かります。
• Hashのアルゴリズムで結合が行われています。
45

Hash
• Hashのアルゴリズム
• 小さいテーブルに対してスキャンし、結合キーに対してハッシュ関数
を適用することでハッシュ値に変換する。それをハッシュテーブルと
呼ぶ。
• そしてもう一方のテーブルをスキャンし、そのハッシュ値がハッシュ
テーブルに存在するかどうかを調べる。
• 合致したら結合を行う。
• Hashの特徴
• ハッシュテーブルを作成する必要があるため、Nested Loopsよりも多く
のメモリを消費する。
• 等値結合（=での結合）でのみ使用可能。
• Nested Loopsで適切な駆動表が存在しない場合や、結合キーにインデッ
クスが存在しない場合などでは、Hashが有効なケースとなります。
46

Sort Merge
• 次はWHERE句を無くしてみます。
• 100000レコード出力されるSQLになります。
47
INNER JOIN tableB b
ON a.a_id = b.a_id
order by b.a_id;

Sort Merge
• ここではMerge Joinと表示されているのが分かります。
• Sort Mergeによる結合が行われています。
48

Sort Merge
• Sort Mergeのアルゴリズム
• テーブルをそれぞれ結合キーでソートする。
• 片方のテーブルをスキャンしながら一致する結合キーが存在したら、
結合する。
• Sort Mergeの特徴
• 対象のテーブルを両方ソートするため、多くのメモリを使用する。
• Hashとは違って不等号を使った結合も可能。
49

• ケース別の最適なアルゴリズム
• 小 – 小
• どんなアルゴリズムでも性能差はほとんどない。
• 小 – 大
• 「小」のテーブルを駆動表としたNested Loopsが最適
• 大 – 大
• HashかMerge Sort
※「大」「小」は駆動表と内部表のサイズ
50

• DBMS毎の制御
• 結合のアルゴリズムはオプティマイザによって自動的に選択されます。
• しかし、DBMSによってはヒント句によって制御が可能です。
• Oracle：ヒント句によって制御可能
• SQL Server：ヒント句によって制御可能
• DB2：制御不可
• PostgreSQL：ヒント句やパラメータで制御可能
• MySQL：アルゴリズムがNested Loopsのみ
51

結合のまとめ
• 結合のまとめ
• 結合のアルゴリズムは主に3つある。
• DBMSによってサポートされているアルゴリズムが異なる。
• ヒント句によって結合のアルゴリズムの制御も可能。
• ただし、どの程度制御できるかはDBMSによって異なる。
52

結合のまとめ
• 結合のまとめ
• 結合のアルゴリズムで最も使用される頻度が高いのはNested Loops
• 結合の処理を速くするには
• 駆動表を小さくする
• 内部表の結合キーにインデックスが存在する
の２つを意識する
• 上記が無理な場合、Hash JoinかSort Margeになる可能性が高い。
• その場合はメモリの容量がカギとなる。
53

実行計画の読み方
様々なSQL文の実行計画
54

• 実行計画の読み方の基本
• 複雑なSQL文の場合、実行計画は階層構造になっています。
• SQLの実行の順序としては、内側の「->」のマークの個所から実行され
ます。
• 同じ階層の場合は、上から順に実行されます。
• 最終的なコストは、それぞれのコストの合計値になります。
• 基本的にはコストが低いほうがパフォーマンスが高くなると考えて良
いが、コストの値が直接速度に比例するわけではない。
55

• Nested Loopsの場合
• Nested Loopの横のコストは、1と2のそれぞれのコストの合計となる。
• 最初にレコード件数の少ないテーブルを絞り込み、そのあとに結合を
行う。
56
1. tableBのレコードを絞り込み
2. tableAのレコードと結合

• Hashの場合
57
1. tableBのレコードを絞り込み
2. tableAのレコードを絞り込み
3. Hashによる結合

• Sort Mergeの場合
58
2. tableBをキー順にスキャン
結合キーが一致したら結合
1. tableAをキー順にスキャン

演習問題
様々なSQLの実行計画を読み解いてみましょう
59

演習問題
• 演習問題
• 今までの実行計画は、全件検索かWHERE句を用いて絞り込みを行った
SELECT文のみでした。
• しかし、実際に使用される現場のSQLではソートや集計など、様々な
処理が施されています。
• それぞれの処理を行うことで実行計画にどのような変化があるのかを
読み解いてみましょう。
60

演習問題
• 演習問題
• 以下のSQL文の実行計画を確認してみましょう。
61
-- ORDER BY ①
SELECT * FROM tableB
WHERE a_id BETWEEN 1 AND 100
ORDER BY b_id;
-- ORDER BY ②
ORDER BY a_id;
-- ORDER BY ③
ORDER BY a_id DESC;

演習問題
• 演習問題
62
-- LIMIT
LIMIT 50;
-- ORDER BY & LIMIT
ORDER BY b_id
LIMIT 50;

演習問題
• 演習問題
63
-- GROUP BY
SELECT value, count(*)
FROM tableB
GROUP BY value;
-- GROUP BY & HAVING
FROM tableB
GROUP BY value
HAVING count(*) > 100;
-- COUNT
SELECT count(*)
FROM tableB;

演習問題
• 演習問題
64
-- GROUP BY & ORDER BY
SELECT value FROM tableB
GROUP BY value
ORDER BY value;
-- WHERE & GROUP BY
FROM tableB
WHERE b_id < 1000
GROUP BY value;

演習問題
• 演習問題
65
-- UNION ALL
SELECT a_id FROM tableA
UNION ALL
SELECT a_id FROM tableB;
-- UNION
UNION
-- EXCEPT
EXCEPT

演習問題
• 演習問題
66
-- EXISTS ①
SELECT * FROM tableA a
WHERE EXISTS (SELECT * FROM tableB
WHERE a_id = a.a_id AND value = 1
AND a_id BETWEEN 1 AND 200);
-- EXISTS ②
SELECT * FROM tableB b
AND value = 1
AND EXISTS (SELECT * FROM tableA
WHERE a_id = b.a_id);

演習問題
• 演習問題
67
-- EXISTS ③
WHERE EXISTS (SELECT * FROM tableB
WHERE a_id = a.a_id
AND value = 1);
-- EXISTS ④
WHERE value = 1
AND EXISTS (SELECT * FROM tableA
WHERE a_id = b.a_id);

演習問題
• 演習問題
68
-- INを使ったサブクエリ ①
SELECT * FROM tableA
WHERE a_id in (SELECT a_id FROM tableB
WHERE value = 1
AND a_id BETWEEN 1 AND 200);
-- INを使ったサブクエリ ②
AND value = 1
AND a_id IN (SELECT a_id FROM tableA);

演習問題
• 演習問題
69
-- インラインビューを使用したサブクエリ
INNER JOIN (SELECT value, max(a_id) a_id
FROM tableB
GROUP BY value) b
ON a.a_id = b.a_id;

参考資料
実際の検証結果
※必ずしも全く同じ結果になるとは限りません
70

参考資料
• ORDER BY ①
• ORDER BYを使用すると、取得結果を並び替える必要があるため、並び
替えの処理のコストが上乗せされます。
71

参考資料
• ORDER BY ②
• ORDER BYをしているが並び替えのコストが発生していません。
• その理由が分かりますか？
72

参考資料
• ORDER BY ③
• 並ぶ順序が逆になっただけ。コストは②から変化なし
73

参考資料
• LIMIT
• 取得件数を制限するので、コストは上乗せされず、むしろカットされ
る。
74

参考資料
• ORDER BY & LIMIT
• 並び替えの分のコストは上乗せされるが、LIMITにより件数を制限して
いるため、全てのレコードがソートされるまで待つ必要はなく、その
分のコストはカットされている。
75

参考資料
• COUNT
• 集約の処理が行われた場合、Aggreateが使用される。
76

参考資料
• GROUP BY
• GROUP BYした場合には、HashAggregate またはGroupAggregate が使用さ
れる。
77

参考資料
• GROUP BY & HAVING
78

参考資料
• WHERE & GROUP BY
• 先に絞り込んだ分コストは小さくなる。
79

参考資料
• GROUP BY & ORDER BY
80

参考資料
• UNION
• Appendで2つの実行結果を足した後、並び替えて重複を削除している。
81

参考資料
• UNION ALL
• 重複を削除する必要がないため、並び替えの処理のなく、UNIONより
もコストが軽い
82

参考資料
• EXISTS ①
• 内部の動きは結合と同じ
84

参考資料
• EXISTS ②
85

参考資料
• EXISTS ③
86

参考資料
• EXISTS ④
87

参考資料
• INを使ったサブクエリ ①
88

参考資料
• INを使ったサブクエリ ②
89

参考資料
• インラインビューを使用したサブクエリ
90

統計情報
• 統計情報
• DBMSが管理する統計情報には様々なものがあります。
• 各テーブルのレコード数
• 各テーブルの列数と列のサイズ
• 列値の値の個数
• 列値の分布
• 列内のNULLの数
• インデック情報
などがあります。
92

統計情報
• 統計情報の更新方法
• 最適な実行計画は統計情報をもとに決定しています。
• DBMSが定期的に自動で取得する場合が多いが、大量のデータを更新し
た直後などは、手動で取得を行う必要があります。
93
DBMS コマンド
Oracle
EXEC
DBMS_STATS.GATHER_TABLE_STATS(OWNN
AME => スキーマ名, TABNAME => テーブル名)
SQL Server UPDATE STATISTICS テーブル名
DB2 RUNSTATS ON TABLE テーブル名
PostgreSQL ANALYZE テーブル名
MySQL ANALYZE TABLE テーブル名

統計情報
• 統計情報の重要性
• 統計情報が実行計画にどのように影響するかを確認してみます。
• 1レコードしか存在しないテーブルに対して実行計画を取得していま
す。
• その場合取得行数は１となっています。
94

統計情報
• 次にレコードを100000件インサートし、統計情報を更新しない状態で
再度実行計画を取得してみます。
• すると2件というおかしな件数になっているのが分かります。
95

統計情報
• analyzeコマンドを実施し、最新の統計情報を取得して再度実行計画を
取得した場合は、正しい結果になっているのが分かります。
96

統計情報
• 以上の結果からわかるように、正しい統計情報が取得できないとオプ
ティマイザが求めた実行計画が最適でない状況になることがあります。
• 速度が遅い場合や大量のデータを扱う場合には統計情報を意識するよ
うにしましょう。
97

実行計画と統計情報のまとめ
• SQLが遅いと感じたら
• 実行計画を確認し、インデックスが適切に使用されているかどうかを
確認しましょう。
• 結合を使ったSQLが遅いと感じたら
• 実行計画を確認し、どのアルゴリズムが使用されている確認しましょ
う。
• 結合を速くするには、結合する側のテーブルの行数を少なくし、結合
される側のテーブルの結合キーにインデックスを使用することです。
• 大量のデータを更新したら
• 統計情報も最新に更新しましょう。
98

参考資料
Oracleの場合の実行計画
99

Oracleの実行計画
• Oracleの実行計画
• Oracleの場合、実行計画を確認する際に複数のオプションが選択でき
ます。コマンド実行後にSQL文を実行すると、実行計画の確認ができ
ます。
100
AUTOTRACEオプション内容
set autotrace on explain 実行結果と実行計画を表示。
set autotrace on statistics 実行結果と統計情報を表示。
set autotrace on 実行結果と実行計画と統計情報を表示。
set autotrace traceonly 実行計画と統計情報を表示。
set autotrace off autotraceをオフにする。

101
SQL> SELECT * FROM tableA;

102
SQL> SELECT * FROM tableA WHERE a_id = 1;

103
SQL> SELECT a_id FROM tableA WHERE a_id = 1;

• Nested Loops
104
SQL> SELECT * FROM tableA a INNER JOIN tableB b ON a.a_id = b.a_id
WHERE b.value = 1 AND b.a_id = 10;

• Hash Join
105
SQL> SELECT * FROM tableA a INNER JOIN tableB b
ON a.a_id = b.a_id WHERE b.value = 1;

• HAVINGとWHEREの比較
• WHEREの場合
106
SQL> SELECT value, count(*) FROM tableB
WHERE value = 30
GROUP BY value;

• HAVINGとWHEREの比較
• HAVINGの場合
107
SQL> SELECT value, count(*) FROM tableB
GROUP BY value
HAVING value = 30;

• UNIONとUNION ALLの比較
• UNIONの場合
• ソートの処理が入る。
108
SQL> SELECT a_id FROM tableA
UNION

• UNIONとUNION ALLの比較
• UNION ALLの場合
• ソートの処理はない。
109
SQL> SELECT a_id FROM tableA
UNION ALL

2019年度若手技術者向け講座実行計画

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Similar a 2019年度若手技術者向け講座実行計画

Similar a 2019年度若手技術者向け講座実行計画 (20)

Más de keki3

Más de keki3 (20)