構文解析したツリー〜実行の間の作業…の前半
「関係代数」
- 「リレーション」の意味
- 「テーブル」と認識すれば問題無い
- ER図のRelationは異なる
- 「関係代数」とは
- 「リレーション」に対する、(コンピュータ科学における)演算の体系
- union, 直積, where, join 等、多くの物に対応する演算がある
- ただしSQLと関係代数は全く一致するわけではない
論理プランと物理プラン
- SQLを関係代数の言葉に変換したのが論理プラン
- 論理プランを手続きのレベルにまで変更したのが物理プラン
タプル、カラムについて
- タプル … 「レコード」みたいな物
- カラム … あるいは「属性」
- 両方とも順序をに意味がない(ここら辺の意味は気にしなくても良いかも)
和、共通部分、差
- UNION, INTERSECT, EXCEPT に相当
- (しかしUNION以外使わないような…)
- 関係代数では同じタプルは区別しない(ここら辺の意味は気にしなくても良いかも)
選択、射影、直積
- 選択 … WHERE 句に相当
- 射影 … SELECT 句に相当?
- 直積 … FROM 句に相当
結合
- いくつか種類がある(等結合、自然結合、準結合(Wikipediaより))
- 等結合
- 「JOIN 〜 ON 〜 = 〜」に相当
- 直積と選択で表現できる
本書の手順参照…
前述の手順の通りだと、非常に効率が悪い
- 1000 × 30 で 30000 タプルが作成される
直積から等結合への変換
- 等結合は直積/選択/射影の組み合わせで出来る
- 直積をうまく変換できれば、タプル数が大きく小さくなる
- (ただし、等結合自体コストが高いのは変わらない)
- 例 … 図3-5
ビューの中身で置き換えてからプランナにかけることになる
SELECTの形から最適なプランを選択するのには限度がある
- 例: 3-4
- 性別でのフィルタリングと結合のどちらを先に行うべきか?
- データやインデックスがある場合等で異なる
- 実際に処理してみないと分からない
- 毎回違うSQLを実行する場合は計測しにくい
- 同じSQLを繰り返す場合は予測しやすい
L1/L2キャッシュ
- 例: Mac Book Pro (2013年)
- 32K+32K/256K/6M
- 1.5ns/3ns/8ns/80ns (くらい)
- TLB の影響もある?