#SQL文のチューニング
具体的な解決策までは書いてませんが、チューニングのヒントを簡単に整理しました。
オプティマイザモードがコストベースモードであるか、ルールベースのモードであるか確認しておく。
数値は数値型のタイプで、文字は文字型のタイプで比較する。
phpなどのインタープリタ言語の経験が主なメンバーに注意させていますが、書いたSQLを見ると、よくデータ型を無視して比較します。オプティマイザが陰でキャスト処理してくれていることをお忘れなく。このくらい別にいいでしょーと言われますが、大量データになると悪魔に出会います。
WHERE句に比較条件にインデックスを利用する場合は、インデックスの列を記述する。
当たり前なことですが、コードレビューで以外と見つかります。
複数の列がインデックス一つで指定された場合、WHERE句にすべてを記述する。
複数の列がインデックス一つで指定された場合、前方の列を指定してインデックス範囲を狭める。
複合インデックスの使用では気をつけましょう。
インデックスになる列は型など変更しない。
ここまでくると、設計の見直しになります。
インデックス列にNULL値を使用しない。
NULLはブラックホールと思えば、理解が早いです。NULLに触れたレコードは消える！
あれこれ悩まずに「NOT NULLと規定値」に決めましょう。統計関連テーブルでは特に注意です。
否定形で指定する場合にはインデックスを使わない。できるだけ否定形を使わない。
否定形を使わないといけない場合は手を止めて設計を疑いましょう。
ORを使用すると、インデックスが使われないことがある。
ORはより神経を立てて使用します。SQLは絞る（AND）感覚で書きたいです。
不必要にDUALテーブルを使用しない。(Oracle)
インデックスのデータを20％以上参照すると予想される場合、インデックススキャンを避ける。
実行プランで「スキャン」が見えたらアウト！テーブルスキャンが見えらたさらにアウト！
不必要にDBMSで提供された関数（SUM、SGIN、DECODE、NVLなど）を使用しない。
インデックス列にLIKEで比較する場合は、必ず後ろに比較演算子（%）を位置する。前方に位置するとインデックスを使用しなくなる。
大量データの検索では絶対に禁止です。開発環境では引っかからなくリリースした途端、痛い目にあうパータンです。
あいまい検索のため、使わざるをえない場合もあるが、覚悟の上です。
ヒントを適切に使用する。
実行プランを熟知してから使いましょう。
アクセスパスの優先順位を知っているべきである。
チューニングの基本項目です。
1.ROWIDによる単一ロー
2.クラスタ結合による単一ロー
3.UNIQUEかPKを持つハッシュ・クラスタのキーによる単一ロー
4.UNIQUEかPKによる単一ロー
5.クラスタ結合
6.ハッシュ・クラスタのキー
7.インデックスクラスタキー
8.複合カラムインデックス
9.単一の列のインデックス
10.インデックスが設定された列で指定範囲の検索
11.インデックスが設定された列で指定なし範囲の検索
12.ソート - マージ結合
13.インデックスが設定された列でMAXまたはMIN
14.インデックスが設定された列でORDER BY
15.フルテーブルスキャン
#メモ
オプティマイザが段々賢くなりいつかはチューニングは人間から離れるのでしょうか・・・
しかし、何であっても基礎は底力に間違いありません。