データベースシステム論11 － データベースの構成
•
1 gefällt mir•3,019 views
静岡大学情報学部「データベースシステム論」講義スライド 第11回：データベースの構成
![データベースシステム論
2016年度 前期 水曜 1･2時限 情24教室
担当：横山昌平
データベースシステム論 第 回2016 [ 11 ] 1p.](https://image.slidesharecdn.com/11-140106131504-phpapp02/85/11-1-320.jpg)
![講義計画
• 関係データベースの歴史と基本概念
• SQLの基礎と応用(演習を含めつつ)
• データベースの設計と構成
• SQL問い合わせ処理とそれを支える技術
• 関係データモデル以外のデータベース
データベースシステム論 第 回2016 [ 10 ] 2p.
※現時点での予定です。進捗に応じて変更します。
27Apr.
20Apr.
13Apr.
25May
18May
11May
1June
8June
22June
15June
13July
6July
29July
20July
27July](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (19)
Ähnlich wie データベースシステム論11 － データベースの構成
Ähnlich wie データベースシステム論11 － データベースの構成 (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (7)
データベースシステム論11 － データベースの構成
- 1. データベースシステム論 2016年度 前期 水曜 1･2時限 情24教室 担当：横山昌平 データベースシステム論 第 回2016 [ 11 ] 1p.
- 2. 講義計画 • 関係データベースの歴史と基本概念 • SQLの基礎と応用(演習を含めつつ) • データベースの設計と構成 • SQL問い合わせ処理とそれを支える技術 • 関係データモデル以外のデータベース データベースシステム論 第 回2016 [ 10 ] 2p. ※現時点での予定です。進捗に応じて変更します。 27Apr. 20Apr. 13Apr. 25May 18May 11May 1June 8June 22June 15June 13July 6July 29July 20July 27July
- 3. データベースシステム論 [答え合わせ]演習4 正規化テーブルの作成とVIEW データベースシステム論 第 回2016 [ 11 ] 3p.
- 4. 提出課題4 [本日の授業終了まで] データベースシステム論 第 回2016 [ 11 ] 4p. • 正規化テーブルからビューを作ってみよう！ • 第一正規形に見えるv_wineというビューを作 れ！ • テーブルが１つの方がアプリからは使いやすいで しょ？ ワインセット ソムリエ 年齢 価格 ワイン 評価 高級白ワイン 田崎信哉 50 10000 シャルドネ カテナ ★★★ 高級白ワイン 田崎信哉 50 10000 セミヨンブロークンウッド ★★★ 高級白ワイン 田崎信哉 50 10000 おたる ★ お買い得白ワイン 横山昌平 36 3000 おたる ★★ お買い得白ワイン 横山昌平 36 3000 デリカート白 ★★★ お買い得白ワイン 横山昌平 36 3000 ガロフォリ白 ★ お勧めワインセット 田崎信哉 50 150000 シャトー・ジレット ★★ お勧めワインセット 田崎信哉 50 150000 オーパスワン ★★★ お勧めワインセット 田崎信哉 50 150000 ヒル・オブ・グレイス ★
- 5. 提出課題4の答え • 第一正規形の単一テーブルに戻すSQL データベースシステム論 第 回2016 [ 11 ] 5p. CREATE VIEW v_wine AS SELECT t_wine.ワインセット, t_sommelier.ソムリエ, 年齢, 価格, t_wine.ワイン, 評価 FROM t_wine NATURAL JOIN t_wine_set NATURAL JOIN t_sommelier;
- 6. データベースシステム論 第１１回 データベースの構成 データベースシステム論 第 回2016 [ 11 ] 6p.
- 7. 記憶領域の構成 • コンピュータが情報を記憶する仕組みとして多層 のアーキテクチャが採用されている。 • 主記憶 • CPU内のキャッシュメモリ • コアメモリ • 二次記憶 • 磁気ディスク(HDD)・SSD • 三次記憶 • 磁気テープ • 速さ • 主記憶＞二次記憶＞三次記憶 • 価格 • 主記憶＜二次記憶＜三次記憶 データベースシステム論 第 回2016 [ 11 ] 7p.
- 8. 記憶領域の階層 データベースシステム論 第 回2016 [ 11 ] 8p. キャッシュ コアメモリ 磁気テープ 磁気ディスク CPU データ要求 データ転送 主記憶 (揮発性を有する) 二次記憶 三次記憶
- 9. データの格納場所 • 磁気ディスク(HDD・SSD) • 容量・価格・性能が釣り合っている • コアメモリに対してアクセス時間がかかる • シーク時間※ • ディスクヘッドをトラックまで移動させる時間 • 回転待ち期間※ • ディスクヘッドに要求したブロックが来るまでの時間 • 転送時間 • ブロックに対し読み書きする時間 ※SSDはシーク時間・回転待ち時間が無いのでHDDより高速 • (稀に)コアメモリ • 容量の面でHDDに劣るがアクセス速度が速い • 電源断で揮発する欠点が データベースシステム論 第 回2016 [ 11 ] 9p.
- 10. RAID Redundant Arrays of Independent Disks • 複数のディスクを使い仮想的な１つのディスク を構成する技術 • 例えば２台のHDDを持っていたとして… • Plan A • ２つのHDDにデータの細切れを分散して保存しておけば、 転送時間が削減できるので高速化が見込める！ →この事をRAID0と言います。 • Plan B • 壊れるのが怖いので、片方のHDDと全く同一のデータを もう片方のHDDにも入れておこう… →この事をRAID1と言います。 データベースシステム論 第 回2016 [ 11 ] 10p.
- 11. RAID0 と RAID1 データベースシステム論 第 回2016 [ 11 ] 11p. D C B A B A D C D C B A D C B A HDD1 HDD2 HDD1 HDD2 RAID0 ストライピング RAID1 ミラーリング B A D C HDD2 HDD4 B A D C HDD1 HDD3 RAID0+1
- 12. RAID5 • ストライピングで読み込み速度向上 • A,Bの同時読み込みが可能 • パリティにより格納効率の向上 • RAID0+1なら4台必要の所、3台で構成 データベースシステム論 第 回2016 [ 11 ] 12p. D C B A C A HDD1 P(C,D) B HDD2 D p(A,B) HDD3 HDD1台の故障に耐える！ 何故？
- 13. パリティの仕組み • ビット列にある1の個数に関係したフラグ • 偶数個ならば「0」、奇数個ならば「1」をとる 例：10100010の格納 データベースシステム論 第 回2016 [ 11 ] 13p. HDD1 HDD2 HDD3 １ ０ １ １ １ ０ ０ ０ ０ １ ０ １ Ｐ Ｐ Ｐ Ｐ 奇数 奇数 偶数 奇数
- 14. パリティの仕組み • ビット列にある1の個数に関係したフラグ • 偶数個ならば「0」、奇数個ならば「1」をとる 例：10100010の格納 データベースシステム論 第 回2016 [ 11 ] 14p. HDD1 HDD2 HDD3 １ ０ １ １ １ ０ ０ ０ ０ １ ０ １ 奇数 奇数 偶数 奇数 故障！ newHDD １ ０ ０ １ 1^0→ 1^1→ 0^0→ 1^0→ XOR,排他的論理和
- 15. 空 フレーム 空 フレーム 空 フレーム バッファ • データベース全体を主記憶に載せる事は(多く の場合)現実的では無いので、必要に応じて二 次記憶から主記憶へデータを呼び出す データベースシステム論 第 回2016 [ 11 ] 15p. ページ #1 ページ #3 ページ #2 ページ #4 ページ #5 ページ #6 ページ #1 ページ #5 空 フレーム 空 フレーム 空 フレーム ページ #3 Read Read Write dirty ページ #3 フェッチ
- 16. フェッチとプリフェッチ • 二次記憶からバッファへデータを読み込む事を フェッチと言う • 単純には、CPUからデータを要求された時点で、 もしそのデータがバッファ上に無ければ、 フェッチする。 • データベースではしばしばフレームを超えた順 次アクセスが発生する。 • その場合、あるフレームがフェッチされた時に 次に要求されるフレームの予想がつく為、あら かじめバッファに読み込んでおく。 • これをプリフェッチと言う。 データベースシステム論 第 回2016 [ 11 ] 16p.
- 17. レコード(タプル・行)格納 • 固定長か可変長かによって格納方法が異なる • 固定長レコード • CHAR型やINT型の様に長さが一定のカラムだけからなる テーブルのレコード • 可変長レコード • VARCHAR型やTEXT型のように長さが可変のカラムを１ つでも有するテーブルのレコード • Large Object • Binary Large Object (BLOB)：バイナリデータ用 • Character Large Object (CLOB)：文字列用 • VARCHAR型で表現しきれない大きなデータ(例：映画の 動画ファイル、新聞記事)を格納するためのデータ型。 • 特殊な格納方法を採る。 データベースシステム論 第 回2016 [ 11 ] 17p.
- 18. 固定長レコード データベースシステム論 第 回2016 [ 11 ] 18p. 型 サイズ 空港コード char(3) 3 便数 int 4 開港日 date 4 1 2 3 4 5 6 7 8 9 10 11 空港コード 便数 開港日 NRT 600 1978年5月20日 HND 1000 1931年8月25日 • 利点 • n番目のレコードのm番目のタプルの位置の計算が簡単 • 欠点 • 無駄なスペースをとる。 • 空港コードが2文字の場合でも3バイト必要 • 便数の最大値1000は10bitで表現可能だが、必ず4byte文のスペースが確保される ※ 但し、実際の実装上は、各カラム が8byte毎の境界を超えないように保 存されるDBMSも多い(境界整列)
- 19. 可変長レコード • 利点 • 格納効率が良い • 欠点 • 可変長カラムの終端が不明！ →どうする？ データベースシステム論 第 回2016 [ 11 ] 19p. 型 サイズ 空港コード varchar(3) 3 空港名 varchar(10) max10 1 2 3 4 5 6 7 8 9 10 11 空港コード 空港名 NRT 新東京国際空港 HND 東京国際空港
- 20. 可変長レコードの格納戦略 • セパレータを使う • 値に含まれない特別な値を使う • アドレス配列を使う • 各カラムの先頭にカラムの長さを格納する データベースシステム論 第 回2016 [ 11 ] 20p. HND 東京国際空港| | NRT 新東京国際空港| | HND 東京国際空港 NRT 新東京国際空港3 6 3 7 HND 東京国際空港6 3 NRT 新東京国際空港33 ※ 日本語等のマルチバイト文字は文字コードDBMSの実装に依存するので注意
- 21. 実際のシステムでは • IBM DB2は，固定長属性をレコードの先頭から の相対的位置に格納する．可変長属性に対して はアドレス配列とそのあとに実際の値を格納す る方式をとる． • Microsoft SQL Serverも同様な方式をとる． • Oracleは固定長属性も含めすべての属性は可変 長であると考え属性の長さと値を対にして格納 する． データベースシステム論 第 回2016 [ 11 ] 21p.
- 22. 可変長レコードの更新 • 更新後の可変長属性の長さが大きくなる場合、無 理やり入れると続くデータが消えてしまう • 可変長カラムでも、あらかじめ指定された最大長 を確保することが考えられる。この場合は全体と しては固定長カラムとなり、可変長カラムの更新 に伴うデータの移動は起きない。ただし使用しな い領域は増え、現実的では無い。 • どうする？ データベースシステム論 第 回2016 [ 11 ] 22p. 1 2 3 4 5 6 7 8 9 空港名 varchar(10) コードchar(3) 4 成田空港 NRT 1 2 3 4 5 6 7 8 9 7 新東京国際空港 更新！
- 23. 行移行 データベースシステム論 第 回2016 [ 11 ] 23p. 1 2 3 4 5 6 7 8 9 空港名 varchar(10) コードchar(3) 4 成田空港 NRT 1 2 3 4 5 6 7 8 9 7 新東京国際空港 更新！ 1 2 3 4 5 6 7 8 9 空港名 varchar(10) コードchar(3) (アドレス) (空) NRT 1 2 3 4 5 6 7 空港名 varchar(10) 新東京国際空港 別のメモリ領域(ブロック) 更新後 更新前
- 24. 行連鎖 • 複数のブロックにまたがってデータを格納 • ブロックサイズを超える大きなデータの場合等 データベースシステム論 第 回2016 [ 11 ] 24p. 1 2 3 ・・・・・・・・・・・ flag 連鎖先 プロフィール yes (アドレス) 1977年に横浜生まれ、幼稚園 1 2 3 ・・・・・・・・・・・ flag 連鎖先 プロフィール yes (アドレス) は近くのミッション系に通う 1 2 3 ・・・・・・・・・・・ flag 連鎖先 プロフィール NO DBシステム論の教壇に立つ。 中略
- 25. LOB・BLOB・CLOB • 映画や音楽のようにブロックよりも大きく，しかも連 続してアクセス（再生）されるデータは連続したブ ロックとして格納する．これを特にBLOB（Binary Large OBject）と呼ぶ． • 巨大な文字列データはCLOB（Character Large OBject） と 呼 ば れ る ． BLOB と CLOB を 総 称 し て LOB （ Large OBject）という． • OracleはBLOBとCLOBを，連鎖行を用いて実現する． • SQL ServerはLOBを，B+木を用いて実現しそのルートノード へのポインタを通常のレコードのカラムに格納する． • IBM DB2はLOBを別テーブルで実現し（一般に複数ページにま たがる），そのレコード識別子をカラムに格納する． • PostgreSQLは厳密にはLOBを持たないが、TEXT型という同じ 役割を持つデータ型が用意されている。 データベースシステム論 第 回2016 [ 11 ] 25p.
- 26. 格納方法 • DBMSは1つ以上のデータベースを管理する。 • データベースは1つ以上のテーブルスペースを管理 する。 • テーブルスペースは1つ以上のデータファイルに保 存される。 データベースシステム論 第 回2016 [ 11 ] 26p. データファイル データベース テーブルスペース テーブル スペース データファイル データファイル データベース テーブルスペース テーブル スペース データファイル DBMS
- 27. (データファイルへの)格納方法 • ディスクブロック • HDDの最少読み込み単位 • ページ • 連続した1つ以上のディスクブロックの塊 • エクステント • 連続したページの集まり • セグメント • エクステントの集まり(非連続でも良い) データベースシステム論 第 回2016 [ 11 ] 27p. エクステント ディスクブロック ページ セグメント
- 28. テーブル生成とデータの格納 • エクステントを1つ含んだ新しいセグメントが 割り当てられる。 • データ挿入に伴いエクステントの領域が不足し た場合、新しいエクステントをセグメントに追 加する。 • DBMSによって1つのテーブルを１つのエクス テントに格納するもの(Oracle)もあれば、複数 のテーブルを1つのエクステントに格納できる もの(SQL Server)もある。 データベースシステム論 第 回2016 [ 11 ] 28p.
- 29. タプルの挿入 • 各タプルは、通常エクステントの最初のページか ら挿入されていく、それが一杯になると、次の ページに挿入される． • ページの使用率は、使用領域率の閾値と空き領域 率の閾値を指定することで制御することができる。 • つまり現実にはディスクには単にデータのみが格納され る訳では無く、これらの統計情報等もメタデータとして ヘッダ領域に格納されている。 • 初期エクステントが一杯になったら、次のエクス テントが割り当てられて、そこに同様にして挿入 される。 データベースシステム論 第 回2016 [ 11 ] 29p.
- 30. ページの構造 • レコードが格納されたアドレス(とサイズ)をス ロットとしてヘッダ領域の一部に配置 • サイズはレコードの方に配置するDBMSもある • 固定長の場合はサイズは一定なのでシステムカタロ グ(スキーマの定義)に一度だけ格納する方式もある データベースシステム論 第 回2016 [ 11 ] 30p. スロット レコード ヘッダ
- 31. インデクス • インデクスとは？ • 主キーに自動的に付与される • 明示的に特定のカラムへ付与する事もできる データベースシステム論 第 回2016 [ 11 ] 31p. データに付随して格納される情報で最も重要なRDBの機能が インデックスは、データベースの性能を向上させ るための一般的な方法です。データベースサーバで インデックスを使用すると、インデックスを使用し ない場合に比べてかなり速く、特定の行を検出し抽 出することができます。しかし、インデックスを使 用すると、データベースシステム全体にオーバー ヘッドを追加することにもなるため、注意して使用 する必要があります。 （出典：PostgreSQL9.3.1公式ドキュメント）
- 32. インデクスの種類 • B-tree, B+tree • ある順番でソート可能なデータに対する等価性や範 囲の問い合わせに対して効果を発揮する。 • Hash • 単純な等価性比較を行う場合に効果を発揮する。 • 空間インデクス(R-Tree) • 多次元空間中での範囲検索や近傍検索に効果を発揮 する。 データベースシステム論 第 回2016 [ 11 ] 32p.
- 33. インデクス格納方法の分類 • クラスタードインデクス • インデクスにより順序付けされたカラムの順序に従 いタプルをディスクへ格納する手法 • 「ソート済み」のデータを格納している • 当然、高速な検索が期待できるが、各テーブルに 1つのみしかクラスタードインデクスは持てない • B-Treeの葉がタプルであるイメージ • アンクラスタードインデクス • インデクスにデータの実態ではなく、タプルのアド レスへのリンクのみを格納する手法 • B-Treeの葉がアドレスであるイメージ データベースシステム論 第 回2016 [ 11 ] 33p.
- 34. 対象カラムによる分類 • ユニークインデクス • キーの値が重複していないインデクスの事 • 主キーやUNIQUEが指定されたカラムへインデクス が付与された場合、必然的にユニークインデクスと なる • ノンユニークインデクス • キーの重複が許されているカラムに対するインデク スの事 データベースシステム論 第 回2016 [ 11 ] 34p. これらは暗黙的に決定されるので、利用者の立場からは気にす る必要はありませんが、問い合わせ処理上、ユニークが保障さ れていない場合の処理とそうでない場合の処理を切り分ける目 的で利用されます。
- 35. B+tree • d次のB+treeの定義 • 値と中間ノード • 1～2d個の整列された値を持つ • 値数+1個のポインタ(最大2d+1)を持つ • 値xの左にあるポインタはx未満の値を持つノードを指す • 値xの右にあるポインタはx以上の値を持つノードを指す • 葉 • d～2d個の整列された値を持つ • 次の葉へのリンクを持つ(B木に比べ順次アクセスで利点) • 一般的に葉の値はタプルを指すポインタ • タプルの値が入って居る場合がクラスタードインデクス データベースシステム論 第 回2016 [ 11 ] 35p. 35 10 25 65 1 3 10 16 25 30 35 40 65 74 索引部 データ部 X＜35 35≦X X＜6510 ≦X＜25 次 64≦X 次 次 次
- 36. Hash • 単に等価検索の場合B+treeではノードをポインタを使 いたどる為、何度もディスクアクセスする必要がある • それに対し、検索したい値から直接格納場所のアドレ スを算出できるタイプのインデクスがHashである • すなわち範囲検索には利用できない • 値とアドレスの組を保存しておけば、検索時に値から タプルの場所を特定できる • 一般的にはHash関数の選定が重要 • お手軽にはDBMS付属のHash関数を使えばよい データベースシステム論 第 回2016 [ 11 ] 36p. 値Ａ Hash関数 アドレスＡ Hash値
- 37. Hash関数とHash値の衝突 • 例：季語データベースと春夏秋冬Hash関数 データベースシステム論 第 回2016 [ 11 ] 37p. 春ページ 夏ページ 秋ページ 冬ページ 風船 草餅 春 春 春夏秋冬 Hash関数 衝突 ページのサイズに収まる量のデータ以上の衝突が起きると、新 にページを用意しなければならない(ページオーバフロー)。ハッ シュ値は1つのアドレスであり、複数のページを持つという事は 複数のアドレスを持つ事である。すなわち検索効率が落ちる。 春ページ
- 38. Postgresで試して見よう • 使用テーブル • zipcode (インストール時に作成したテーブル) • 準備 • zipcodeはインデクスが貼られていない • zipcodeと同じスキーマのzipcode2を作成 • zipcode2に対してインデクスを付与 • zip(なぜか整数型です)にbtree • addr3にhash • 両方のテーブルで性能差を確認 • zipの範囲検索はどうか？ • addr3の等価検索はどうか？ データベースシステム論 第 回2016 [ 11 ] 38p.
- 39. 準備 • SQLは講義HPにもあります。 • テーブルの作成 • zipcode作成時と同じCREATE TABLE 文 • データのコピー • INSERT INTO ～ SELECT ～文 データベースシステム論 第 回2016 [ 11 ] 39p. INSERT INTO zipcode2 SELECT * FROM zipcode; ※INSERT 0 123423と出たら成功
- 40. CREATE INDEX文 • インデクス名 • 任意の名前で良いがテーブル名・カラム名から連想できる名 前にした方が識別しやすい • 例: wine.wid→idx_wine_wid • メソッド • btree / hash / gist / spgist / ginのどれか • UNIQUE • ユニークインデクスなら明示する データベースシステム論 第 回2016 [ 11 ] 40p. CREATE [UNIQUE] INDEX インデクス名 ON テーブル名 USING メソッド (カラム名);
- 41. インデクス作成 • zipにbtreeインデクス • addr3にhashインデクス データベースシステム論 第 回2016 [ 11 ] 41p. CREATE INDEX idx_zipcode2_zip ON zipcode2 USING btree (zip); CREATE INDEX idx_zipcode2_addr3 ON zipcode2 USING hash (addr3); 一見UNIQUEを付けられそうですが郵便番号を共有している異なる住所があります
- 42. インデクスの効果測定 • SELECT文の処理にかかるコストを計測 • EXPLAIN文 • 総コストとクエリツリーを得る • EXPLAIN ANALYZE文 • 総コストと実行時間を得る データベースシステム論 第 回2016 [ 11 ] 42p. EXPLAIN ANALIZE SELECT文; EXPLAIN SELECT文;
- 43. 効果測定1 btree & 等価検索 データベースシステム論 第 回2016 [ 11 ] 43p. QUERY PLAN ------------------------------------------------------------ Seq Scan on zipcode (cost=0.00..3566.79 rows=1 width=100) Filter: (zip = 4328011) (2 行) QUERY PLAN ------------------------------------------------------------ ----------------------- Index Scan using idx_zipcode2_zip on zipcode2 (cost=0.42..8.44 rows=1 width=100) Index Cond: (zip = 4328011) (2 行) 3566.79 8.44vs無し 有り Win!
- 44. 効果測定2 btree&範囲検索 データベースシステム論 第 回2016 [ 11 ] 44p. QUERY PLAN ------------------------------------------------------------ Seq Scan on zipcode (cost=0.00..3875.35 rows=1 width=100) Filter: ((zip >= 4328011) AND (zip <= 4328066)) (2 行) QUERY PLAN ------------------------------------------------------------ ----------------------- Index Scan using idx_zipcode2_zip on zipcode2 (cost=0.42..8.44 rows=1 width=100) Index Cond: ((zip >= 4328011) AND (zip <= 4328066)) (2 行) 3875.35 8.44vs無し 有り Win!
- 45. 効果測定3 hash &完全一致検索 データベースシステム論 第 回2016 [ 11 ] 45p. QUERY PLAN ------------------------------------------------------------ Seq Scan on zipcode (cost=0.00..3566.79 rows=2 width=100) Filter: ((addr3)::text = '城北'::text) (2 行) QUERY PLAN ------------------------------------------------------------ Bitmap Heap Scan on zipcode2 (cost=4.02..11.85 rows=2 width=100) Recheck Cond: ((addr3)::text = '城北'::text) -> Bitmap Index Scan on idx_zipcode2_addr3 (cost=0.00..4.01 rows=2 width=0) Index Cond: ((addr3)::text = '城北'::text) (4 行) 3566.79 11.85vs無し 有り Win!
- 46. 効果測定4 hash &部分一致検索 データベースシステム論 第 回2016 [ 11 ] 46p. QUERY PLAN ------------------------------------------------------------ Seq Scan on zipcode (cost=0.00..3566.79 rows=2317 width=100) Filter: ((addr3)::text ~~ '%城%'::text) (2 行) QUERY PLAN ------------------------------------------------------------ Seq Scan on zipcode (cost=0.00..3566.79 rows=2317 width=100) Filter: ((addr3)::text ~~ '%城%'::text) (2 行) 3566.79 3566.79vs無し 有り 引き分け！ ※等価(完全一致)検索以外ではhashインデクスは働かない
- 47. 実行時間の計測 • ANALIZEを付けて実行時間を見る • マシンスペックに依存する値です • 他のプロセスによるCUP負荷にも依存します →毎回違う結果が出てくる データベースシステム論 第 回2016 [ 11 ] 47p. インデックス無し インデックス有り btree&等価 15.373ms 0.041ms btree&範囲 28.147ms 0.066ms hash&完全一致 28.485ms 0.070ms hash&部分一致 36.720ms 32.708ms ※それに対してコストの値はマシンスペックや環境に依存しない →同じスキーマ・データに対する同じSQL文は必ず同じ結果を得る →値そのものには意味が無いが、値同士の比較により効率的なクエリが分かる
- 48. 次回予告 第１２回 問い合わせ処理と最適化 データベースシステム論 第 回2016 [ 11 ] 48p.
- 49. 第12回 問い合わせ処理と最適化 • SQLがDBMSによってどのように最適化され実 行されるのかについて学びます。 • 来週学ぶこと • クエリツリー • 問い合わせの最適化 • JOINの最適化 • 予習 • 対応箇所：教科書第8～9章 • 関連個所：PostgreSQL 9.3.1文書 -第 46～50章 • http://www.postgresql.jp/document/9.3/html/geqo.html データベースシステム論 第 回2016 [ 11 ] 49p.