結合の実行計画
最後に実行計画の見方を学ぶSQL文は、
結合を行うにはテーブルが2つ以上必要ですので、
Reservations
: | ||
実行計画を取得する対象のクエリは、
SELECT shop_name
FROM Shops S INNER JOIN Reservations R
ON S.shop_id = R.shop_id;
結合のアルゴリズム
一般的に、
2つ目は、
3つ目は、
各DBMSが採用するアルゴリズム
Oracle、
実行計画
----------------------------------------------------------
Plan hash value: 1724488161
② ① ③
-----------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
-----------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 48 | 3 (0)| 00:00:01 |
| 1 | NESTED LOOPS | | 1 | 48 | 3 (0)| 00:00:01 |
| 2 | TABLE ACCESS FULL | RESERVATIONS | 1 | 7 | 2 (0)| 00:00:01 |
| 3 | TABLE ACCESS BY INDEX ROWID| SHOPS | 1 | 41 | 1 (0)| 00:00:01 |
|* 4 | INDEX UNIQUE SCAN | SYS_C004157 | 1 | | 0 (0)| 00:00:01 |
-----------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
4 - access("S"."SHOP_ID"="R"."SHOP_ID")
QUERY PLAN
----------------------------------------------------------------------------------
②
Merge Join (cost=1.27..2.75 rows=10 width=2)
Merge Cond: (s.shop_id = r.shop_id)
-< Index Scan using shops_pkey on shops s (cost=0.00..13.15 rows=60 width=8)
-< Sort (cost=1.27..1.29 rows=10 width=6)
Sort Key: r.shop_id
-< Seq Scan on reservations r (cost=0.00..1.10 rows=10 width=6)
② ① ② ③
+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------+-------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------+-------+
| 1 | SIMPLE | R | ALL | NULL | NULL | NULL | NULL | 10 | 100.00 | |
| 1 | SIMPLE | S | eq_ref | PRIMARY | PRIMARY | 5 | mysql.R.shop_id | 1 | 100.00 | |
+----+-------------+-------+--------+---------------+---------+---------+-----------------+------+----------+-------+
Oracleの場合、
ここでちょっと実行計画の読み方のワンポイントを書いておくと、
これら2つに比べると、
アルゴリズムはオプティマイザが決定する
どのようなアルゴリズムが選択されるかは、
ただ、
これに加えて、
オプティマイザの失敗?
しかし、
3つのアルゴリズムのうち、
メモリ上で処理が完結しなかった場合、
データベースの鉄則 1
結合で一番怖いのは、実行計画を変える
最近のオプティマイザは優秀ですが、
そうした場合、
しかしお気づきのように、
まとめ
本稿では、
- ユーザがデータアクセスの手続きを考えないのがリレーショナルデータベースの理想
- ユーザの代わりに実行計画を考えてくれるのがオプティマイザ
- オプティマイザを正しく動かすには統計情報が正しいことが必須
- しかしオプティマイザが常に正しく動くとは限らない
- そういうときは実行計画を調べる必要があるので、
読めるようにしておこう
今回の演習問題は次のものです。
演習問題
あなたの使うDBMSで、演習問題の解答は筆者のWebサイトおよび技術評論社のWebサイトで公開します。それでは、
参考資料
- 『データベースシステム概論 第6版』
(C. J.Date著/ 藤原譲訳/ 丸善/ 1997年) - 「18章 最適化」
がRDBMSにおける最適化戦略についての概略を知るのに便利です。 - 『Database Management Systems 3rd ed.』
(Raghu Ramakrishnan、 Johannes Gehrke 著、 McGraw Hill Higher Education、 2002年) - オプティマイザの動作については
「12 Overview of Query Evaluation」 を参照してください。また 「14 Evaluating Relational Operators」 は、 Nested Loop、 Sort Merge、 Hashのそれぞれのアルゴリズムを理解するのに役立ちます。