SQL実践入門(ミック)

書籍情報

著者:ミック(著)
発行日:2015-05-15
ISBN:9784774173016
URL:https://gihyo.jp/book/2015/978-4-7741-7301-6

書籍目次

はじめに
謝辞
サンプルコードのダウンロード
本書の構成
第1章 DBMSのアーキテクチャ──この世にただ飯はあるか
- 1.1 DBMSのアーキテクチャ概要
  - クエリ評価エンジン
  - バッファマネージャ
  - ディスク容量マネージャ
  - トランザクションマネージャとロックマネージャ
  - リカバリマネージャ
- 1.2 DBMSとバッファ
  - この世にただ飯はあるか
  - DBMSと記憶装置の関係
    - HDD
    - メモリ
    - バッファの活用による速度向上
  - メモリ上の2つのバッファ
    - データキャッシュ
    - ログバッファ
  - メモリの性質がもたらすトレードオフ
    - 揮発性とは
    - 揮発性の問題点
  - システムの特性によるトレードオフ
    - データキャッシュとログバッファのサイズ
    - 検索と更新，大事なのはどっち
  - もう一つのメモリ領域「ワーキングメモリ」
    - いつ使われるか
    - 不足すると何が起きるのか
- 1.3 DBMSと実行計画
  - 権限委譲の功罪
  - データへのアクセス方法はどう決まるのか
    - パーサ（parser）
    - オプティマイザ（optimizer）
    - カタログマネージャ（catalog manager）
    - プラン評価（plan evaluation）
  - オプティマイザとうまく付き合う
  - 適切な実行計画が作成されるようにするには
- 1.4 実行計画がSQL文のパフォーマンスを決める
  - 実行計画の確認方法
  - テーブルフルスキャンの実行計画
    - 操作対象のオブジェクト
    - オブジェクトに対する操作の種類
    - [Column]実行計画の「実行コスト」と「実行時間」
    - 操作の対象となるレコード数
  - インデックススキャンの実行計画
    - 操作の対象となるレコード数
    - 操作対象のオブジェクトと操作
  - 簡単なテーブル結合の実行計画
    - オブジェクトに対する操作の種類
- 1.5 実行計画の重要性
- 第1章のまとめ
- 演習問題1
  - [Column]いろいろなキャッシュ
第2章 SQLの基礎──母国語を話すがごとく
- 2.1 SELECT文
  - SELECT句とFROM句
    - WHERE句
    - WHERE句のさまざまな条件指定
    - WHERE句は巨大なベン図
    - INでOR条件を簡略化する
    - NULL──何もないとはどういうことか
    - [Column]SELECT文は手続き型言語の関数
  - GROUP BY句
    - グループ分けするメリット
    - ホールケーキを全部1人で食べたい人は？
  - HAVING句
  - ORDER BY句
  - ビューとサブクエリ
    - ビューの作り方
    - 無名のビュー
    - サブクエリを使った便利な条件指定
- 2.2 条件分岐，集合演算，ウィンドウ関数，更新
  - SQLと条件分岐
    - CASE式の構文
    - CASE式の動作
  - SQLで集合演算
    - UNIONで和集合を求める
    - INTERSECTで積集合を求める
    - EXCEPTで差集合を求める
  - ウィンドウ関数
  - トランザクションと更新
    - INSERTでデータを挿入する
    - DELETEでデータを削除する
    - UPDATEでデータを更新する
- 第2章のまとめ
- 演習問題2
第3章 SQLにおける条件分岐──文から式へ
- 3.1 UNIONを使った冗長な表現
  - UNIONによる条件分岐の簡単なサンプル
    - UNIONを使うと実行計画が冗長になる
    - UNIONを安易に使うべからず
  - WHERE句で条件分岐させるのは素人
  - SELECT句で条件分岐させると実行計画もすっきり
- 3.2 集計における条件分岐
  - 集計対象に対する条件分岐
    - UNIONによる解
    - UNIONの実行計画
    - 集計における条件分岐もやはりCASE式
  - CASE式の実行計画
    - 集約の結果に対する条件分岐
    - UNIONで条件分岐させるのは簡単だが……
    - UNIONの実行計画
    - CASE式による条件分岐
    - CASE式による条件分岐の実行計画
- 3.3 それでもUNIONが必要なのです
  - UNIONを使わなければ解けないケース
  - UNIONを使ったほうがパフォーマンスが良いケース
    - UNIONによる解
    - ORを使った解
    - INを使った解
- 3.4 手続き型と宣言型
  - 文ベースと式ベース
  - 宣言型の世界へ跳躍しよう
- 第3章のまとめ
- 演習問題3
第4章集約とカット──集合の世界
- 4.1 集約
  - 複数行を1行にまとめる
    - CASE式とGROUP BYの応用
    - 集約・ハッシュ・ソート
  - 合わせ技1本
- 4.2 カット
  - あなたは肥り過ぎ？痩せ過ぎ？ ──カットとパーティション
  - パーティション
    - BMIによるカット
    - PARTITION BY句を使ったカット
- 第4章のまとめ
- 演習問題4
第5章ループ──手続き型の呪縛
- 5.1 ループ依存症
  - Q.「先生，なぜSQLにはループがないのですか？」
  - A.「ループなんてないほうがいいな，と思ったからです」
  - それでもループは回っている
- 5.2 ぐるぐる系の恐怖
  - ぐるぐる系の欠点
    - SQL実行のオーバーヘッド
    - 並列分散がやりにくい
    - データベースの進化による恩恵を受けられない
  - ぐるぐる系を速くする方法はあるか
    - ぐるぐる系をガツン系に書き換える
    - 個々のSQLを速くする
    - 処理を多重化する
  - ぐるぐる系の利点
    - 実行計画が安定する
    - 処理時間の見積り精度が（相対的には）高い
    - トランザクション制御が容易
- 5.3 SQLではループをどう表現するか
  - ポイントはCASE式とウィンドウ関数
    - [Column]相関サブクエリによる対象レコードの制限
  - ループ回数の上限が決まっている場合
    - 近似する郵便番号を求める
    - ランキングの問題に読み替え可能
    - ウィンドウ関数でスキャン回数を減らす
    - [Column]インデックスオンリースキャン
  - ループ回数が不定の場合
    - 隣接リストモデルと再帰クエリ
    - 入れ子集合モデル
- 5.4 バイアスの功罪
- 第5章のまとめ
- 演習問題5
第6章結合──結合を制する者はSQLを制す
- 6.1 機能から見た結合の種類
  - クロス結合──すべての結合の母体
    - [Column]自然結合の構文
    - クロス結合の動作
    - クロス結合が実務で使われない理由
    - うっかりクロス結合
  - 内部結合──何の「内部」なのか
    - 内部結合の動作
    - 内部結合と同値の相関サブクエリ
  - 外部結合──何の「外部」なのか
    - 外部結合の動作
    - 外部結合と内部結合の違い
  - 自己結合──自己とは誰のことか
    - 自己結合の動作
    - 自己結合の考え方
- 6.2 結合のアルゴリズムとパフォーマンス
  - Nested Loops
    - Nested Loopsの動作
    - 駆動表の重要性
    - Nested Loopsの落とし穴
  - Hash
    - Hashの動作
    - Hashの特徴
    - Hashが有効なケース
  - Sort Merge
    - Sort Mergeの動作
    - Sort Mergeの特徴
    - Sort Mergeが有効なケース
  - 意図せぬクロス結合
    - Nested Loopsが選択される場合
    - クロス結合が選択される場合
    - 意図せぬクロス結合を回避するには
- 6.3 結合が遅いなと感じたら
  - ケース別の最適な結合アルゴリズム
  - そもそも実行計画の制御は可能なのか？
    - DBMSごとの実行計画制御の状況
    - 実行計画をユーザが制御することによるリスク
  - 揺れるよ揺れる，実行計画は揺れるよ
- 第6章のまとめ
- 演習問題6
第7章サブクエリ──困難は分割するべきか
- 7.1 サブクエリが引き起こす弊害
  - サブクエリの問題点
    - サブクエリの計算コストが上乗せされる
    - データのI/Oコストがかかる
    - 最適化を受けられない
  - サブクエリ・パラノイア
    - サブクエリを使った場合
    - 相関サブクエリは解にならない
    - ウィンドウ関数で結合をなくせ！
  - 長期的な視野でのリスクマネジメント
    - アルゴリズムの変動リスク
    - 環境起因の遅延リスク
  - サブクエリ・パラノイア──応用版
    - サブクエリ・パラノイア再び
    - 行間比較でも結合は必要ない
  - 困難は分割するな
- 7.2 サブクエリの積極的意味
  - 結合と集約の順序
    - 2つの解
    - 結合の対象行数
- 第7章のまとめ
- 演習問題7
第8章 SQLにおける順序──甦る手続き型
- 8.1 行に対するナンバリング
  - 主キーが1列の場合
    - ウィンドウ関数を利用する
    - 相関サブクエリを利用する
  - 主キーが複数列から構成される場合
    - ウィンドウ関数を利用する
    - 相関サブクエリを利用する
  - グループごとに連番を振る場合
    - ウィンドウ関数を利用する
    - 相関サブクエリを利用する
  - ナンバリングによる更新
    - ウィンドウ関数を利用する
    - 相関サブクエリを利用する
- 8.2 行に対するナンバリングの応用
  - 中央値を求める
    - 集合指向的な解
    - 手続き型の解（1）──世界の中心を目指せ
    - 手続き型の解（2）──2マイナス1は1
  - ナンバリングによりテーブルを分割する
    - 断絶区間を求める
    - 集合指向的な解──集合の境界線
    - 手続き型の解──「1行あと」との比較
  - テーブルに存在するシーケンスを求める
    - 集合指向的な解──再び，集合の境界線
    - 手続き型の解──再び，「1行あと」との比較
- 8.3 シーケンスオブジェクト・IDENTITY列・採番テーブル
  - シーケンスオブジェクト
    - シーケンスオブジェクトの問題点
    - シーケンスオブジェクトそのものに起因する性能問題
    - シーケンスオブジェクトそのものに起因する性能問題への対策
    - 連番をキーに使うことに起因する性能問題
    - 連番をキーに使うことに起因する性能問題への対策
  - IDENTITY列
  - 採番テーブル
- 第8章のまとめ
- 演習問題8
第9章更新とデータモデル──盲目のスーパーソルジャー
- 9.1 更新は効率的に
  - NULLの埋め立てを行う
  - 逆にNULLを作成する
- 9.2 行から列への更新
  - 1列ずつ更新する
  - 行式で複数列更新する
  - NOT NULL制約がついている場合
    - UPDATE文を利用する
    - MERGE文を利用する
- 9.3 列から行への更新
- 9.4 同じテーブルの異なる行からの更新
  - 相関サブクエリを利用する
  - ウィンドウ関数を利用する
  - INSERTとUPDATEはどちらが良いのか
- 9.5 更新のもたらすトレードオフ
  - SQLで解く方法
  - SQLに頼らずに解く方法
- 9.6 モデル変更の注意点
  - 更新コストが高まる
  - 更新までのタイムラグが発生する
  - モデル変更のコストが発生する
- 9.7 スーパーソルジャー病：類題
  - 再び，SQLで解くなら
  - 再び，モデル変更で解くなら
  - 初級者よりも中級者がご用心
- 9.8 データモデルを制す者はシステムを制す
- 第9章のまとめ
- 演習問題9
第10章インデックスを使いこなす──秀才の弱点
- 10.1 インデックスと言えばB-tree
  - 万能型のB-tree
  - その他のインデックス
- 10.2 インデックスを有効活用するには
  - カーディナリティと選択率
    - [Column]クラスタリングファクタ
  - インデックスの利用が有効かを判断するには
- 10.3 インデックスによる性能向上が難しいケース
  - 絞り込み条件が存在しない
  - ほとんどレコードを絞り込めない
    - 入力パラメータによって選択率が変動する（1）
    - 入力パラメータによって選択率が変動する（2）
  - インデックスが使えない検索条件
    - 中間一致，後方一致のLIKE述語
    - 索引列で演算を行っている
    - IS NULL述語を使っている
    - 否定形を用いている
- 10.4 インデックスが使用できない場合どう対処するか
  - 外部設計による対処──深くて暗い川を渡れ
    - UI設計による対処
  - 外部設計による対処の注意点
  - データマートによる対処
    - データマートを採用するときの注意点
    - データ鮮度
    - データマートのサイズ
    - データマートの数
    - バッチウィンドウ
  - インデックスオンリースキャンによる対処
    - [Column]インデックスオンリースキャンとカラム指向データベース
  - インデックスオンリースキャンを採用するときの注意点
    - DBMSによっては使えないこともある
    - 1つのインデックスに含められる列数には限度がある
    - 更新のオーバーヘッドを増やす
    - 定期的なインデックスのリビルドが必要
    - SQL文に新たな列が追加されたら使えない
- 第10章のまとめ
- 演習問題10
Appendix A：PostgreSQLのインストールと起動
Appendix B：演習問題の解答