Oracle SQLチューニングメモ
最終更新日：
2023-03-16
やりたいこと
-
ある機能が遅い（一定時間内に終わらない）
-
遅延箇所を調べる
-
どうやらSQLだけが遅い
-
そうだ、SQLチューニングしよう
やること
-
SQL*Plusを使えるようにする。SQL Developper入れるとか
-
実行されたSQLを取得する。
-
SQLアドバイザに診断してもらう（SQL Developerでボタン一つでできた）
-
使ってるテーブルのlast_anaylizedを見る（ALL_TAB_STATISTICSテーブル
-
統計情報を集める（自動で集めないようにロックかけてたりする）
-
exec DBMS_STATS.GATHER_TABLE_STATS( ownname => 'スキーマ名' , tabname => 'テーブル名');（引数は他にもいろいろある
-
実行計画をとる（DBMS内にオプティマイザが住んでいて、sqlをどういう順番で何したら一番早いかを統計情報からコストとか計算して選んでいる。その選ばれた手順=実行計画を見ることができる。※計画のときにレコード数とるためにcount(*)はしておらずテーブルが持ってる統計情報をを見ている
-
普通のとり方
-
EXPLAIN PLAN FOR (調べたいSQL)
-
SELECT * FROM table(DBMS_XPLAN.DISPLAY);
-
フリーソフト「A5:SQL Mk-2」の実行計画機能は、使われた/使われてない索引が一覧で見れるて便利
-
実行計画の見方を知る
-
Operation：以下では2種類示す
-
アクセスパス
-
TABLE ACCESS FULL：全表スキャン。テーブルを全部見ていく。件数やカラムが多いと遅いことが多い
-
INDEX UNIQUE SCAN：索引一意スキャン。ユニークキーの索引でシュパッと一瞬で美しく1件とりだす
-
INDEX FULL SCAN：全索引スキャン。索引を全部見てフィルタしていく。行数は変わらないが、200カラムのテーブルを全表スキャンするより、それに10カラムの索引を貼ってフル索引スキャンしたほうが早いことが多い
-
結合
-
NESTED LOOPS ：入れ子ループ。正直はやいのか遅いのかは知らない
-
HASH JOIN ：ハッシュ結合。1行づつハッシュ化するらしい。メリットなどはよく知らない。
-
Predicate Informationは大事。たとえば全表スキャンするときにどんな条件で1行づつフィルタチェックしていったのかがわかる
-
使用テーブルのカラム数、レコード数を調べる
-
便利テーブルを見る。ALL_TABLES, ALL_TAB_STATISTICS, ALL_INDEXES, ALL_SYNONYMS, DBA_SEGMENTS
-
Bツリーindexの仕組みを知る（選ばれ場索引たちを大きさなどの順に並べて、末端にrowidをもってて、rowidでレコードを取得する
-
indexの使い方
-
where用indexで一本釣りする
-
大量カラム・大量レコードのテーブルフルスキャンを、少量索引・大量レコードの索引フルスキャンにする(joinが大量のときに使える)
-
indexを作成する、クエリを修正する
-
再度試す、計測する、実行計画を見る
-
SQLチューニングのドキュメントを漁って読む
参考文献