SQLパフォーマンス詳解オンライン読書会(6)参加ノート:インデックスのみスキャン、ソートなど

クラスタ化インデックスよくわかってないので復習したいところ。

meguro-binary-study.connpass.com

インデックスのみスキャン

• インデックスに含まれる列のみの問い合わせはターブルアクセスが発生しない
  • カバリングインデックスとも呼ばれる
  • 少数の列へのアクセスの場合は優位性はとくにない
    • アクセスする行数とクラスタ化係数によって優位性が決まる
  • postgreSQLはサポートが 遅かったらしい
    • 最新版では対応
  • WHERE句の条件にインデックスにない行が増えたりするとテーブルアクセスが発生し、行数が少なくなるのに遅くなる、という事象が発生するので注意。
  • リーフノード非キー列を格納するINCLUDE句が存在する(postgreSQL/SQL Server)
    • WHERE句には指定しないがSELECT句に指定したい列を指定する？
• 部分インデックス：長さがわからないテキスト列などに使えるインデックス
  • CREATE INDEX .. ON employees (last_name(10))
• インデックスのみスキャンを考えるときは各RDBのindexに含めることのできる列数制限やインデックスサイズ制限に注意する(必要に応じてベンダのドキュメントを参照すること)
  • 大まかな目安(多くのRDBでこの値)
    • 32列
    • 1700Byte~6398Byte

索引構成表

• 復習予定...

• 索引構成表

• クラスタ化係数

• クラスタ化インデックス

• ヒープテーブル

ソートとグルーピング

• ソート処理は一般にパイプライン化出来ない

  • パイプライン化の部分の全体の中での順序が決定する必要があるため

• インデックスをうまく使えばOrder byをパイプライン化できる

• Order Byで指定する列順でindeを作ればOrder By処理は不要にできるケースがある(実行計画から消える)

• (ソート不要のつもりが)ソートが行われてしまう原因を知りたければ、order by 句を完全に含むインデックス定義を使って調べる

オプティマイザは、結果の最後 のレコードを最も早く得られる実行計画を選ぶのです(p133)

• 一般的にリーフノードチェーンの作成は双方向連結リストを使っているのでOrcer byのASC/DESCのコスト差はない
  • ただし複合インデックスの場合はインデックスに含めた各列の順序を合わせる必要がある。
    • ASC,ASCで指定したindexにDESC,DESC問い合わせはOKだがASC,DESCなどを混ぜた問い合わせ使うとソート処理が必要になる。
      • 混在させた問い合わせを使いたい場合は混在させたindexを定義しておく
        • ASC/DESC付インデックスを使う
          • MySQL以外のDBはほぼほぼASC/DESC インデックスに対応
          • MySQLは最新では対応してる(8のどこかから対応)
            • p138の表は少し古い

SQLパフォーマンス詳解