SQLチューニング原論(仮)

もわっとしたイメージ重視のテキトーメモ。正確性、網羅性は重視していない。

チューニングの三原則

  • 仕事量(計算量)を減らす
    • 仕事量は CPUコスト + I/Oコスト とも言える
    • 行単位でデータが必要な場合は行指向、列方向でデータが必要な場合は列指向など
    • 圧縮でI/Oコストを減らす
  • 並列化する
    • アムダールの法則を考慮した上で、効果が望める場合は並列化する
    • SIMD(SQLではなくハードウェアレイヤーでの並列化)
  • 仕事を速くする
    • 処理自体を速くする
    • ディスク→SSD→メモリ→L1-3キャッシュ→レジスタ
    • Software on Silicon とか

式で表すとこうなります。


仕事量(計算量)を減らすのが一番大切

  • データ(オブジェクト)構造が最も大切
    • 表、索引、パーティショニングなど
  • アルゴリズム(実行計画)は、適切なデータ(オブジェクト)構造、統計情報*1SQL文があればクエリーオプティマイザ*2が最適なものを導出してくれる
    • バージョン・パッチ、初期化パラメータ、データの実態(バージョンと初期化パラメータによる)なども実行計画に影響する
    • 実行計画は変わらなくても、direct path read or db file scattered/sequential read がセグメントサイズやダーティーバッファの量によって変わることがある

データ構造の種類

アルゴリズム(実行計画)の種類

アクセスパス
  • 表スキャン
  • 索引スキャン
結合
  • 結合順
  • 結合方法
    • ネステッドループ結合
    • ハッシュ結合
    • ソートマージ結合
  • 結合種類
    • 内部結合
    • 外部結合
    • セミ結合
    • アンチ結合
  • 結合最適化

目次案

  • なぜこの本を書いたか
    • 自分が欲しかった本
    • 自力歩行を目的にしているので、圧倒的に網羅性を意識していない
  • 対象読者
    • SQLチューニングに携わる初心者から上級者まで
  • 全体サマリ
    • 絵で全体像を解説
    • 三原則、RDBMSの仕組み、アルゴリズムは適切なデータ構造、統計情報、SQLから導出されることを具体例で解説
    • チートシート(データ構造、統計情報、実行計画、ヒント、性能劣化原因切り分け)
  • 基本概念
    • 時間短縮のための三原則
      • 計算量を最小化する
      • 並列化する
      • 高速化する
    • SQL実行の流れ
    • ボトルネックの見つけ方
    • チューニング方法
      • 計算量を最小化する(行方向、列方向、圧縮、CPUコストが高い処理、一括化)
      • 並列化する(パラレルクエリー/DMLの使い所)
      • 高速化する(キャッシュ系)
  • 計算量を最少化するための設計と実装
    • オブジェクト設計
      • 索引設計
      • パーティショニング設計
  • SQLコーディング
  • 統計情報
    • 統計の種類
      • 表統計
      • 列統計
      • 索引統計
      • パーテイション統計
    • 運用方法
  • ボトルネックの見つけ方
    • 実行計画の取得方法
    • 実行計画の読み方
    • 実行計画のオペレーション
      • アクセスパス
      • 結合方法
      • 結合順
  • 人為的に実行計画を制御する
    • ヒントの使い方
  • 突然性能劣化時の分析方法
  • SQLチューニング演習問題(10問)
  • 付録
    • 統計情報
    • 実行計画のオペレーション
  • 参考情報
  • コラム
      • アムダールの法則
      • プロセスの状態遷移
      • 意識されていないページキャッシュとストレージキャッシュ

前提

  • SQL単体性能について書いている*3

*1:オプティマイザ統計情報、表統計、索引統計、列統計、デフォルト統計、ディクショナリ統計、システム統計などがある

*2:ここではコストベースオプティマイザとする

*3:enqueue、latch、mutexといった並行処理での競合については考慮していない