不勉強なんで、余り気にしなかった（しなくても動いてた）ＳＱＬの勉強を少ししてました。
してたというか、せざるを得なかったというか。

今やってるシステムのメイン部分がＷｅｂ化され、Ｊａｖａベースになっているんですが、それに伴ってデータベースの構造が変わってしまいました。
（ＤＢサーバすら違う）
表の名前も、列名も違う。

これだと既存部分の修正が大きくなるので、ＤＢリンクを使ってＶＩＥＷを前のイメージで作ってるわけなんですが（何がなにやら、という方済みません、今日のは読み飛ばしてください）、ＳＱＬが果てしなく重くなってしまいました。

図書館に行って本を借りようとしたら、本のある場所がわからないので、司書さんに聞いたら、
新米司書→ベテラン司書→館長まで話が行ってしまい、
さらに同じ市内の図書館に問い合わせされ、さらにそれが国会図書館までいって、その結果が伝書鳩で返ってくるような感じです。

おいおい、本はインデックスで分類されていて、ジャンルとかで場所あるだろう、その場所教えてくれよ、って感じなのであります。

データベースも同じようにインデックスというものがあり、それを参照することで検索を早く出来るのですが、全然それが参照されない状態（全検索）になっている為に遅いのです。

で、いろいろ調べてみたら。
まず、検索時、from句の中身は、データが多いものから書くようにするそうです。
なので、マスタ系の件数がそう変わらないもののカウンタを取り、並べ替え。
それだけで今まで見てくれなかったインデックスを見るようになり、２０分待っても返ってこなかったのが、８分まで短縮されました。
しかしたった３件のデータで８分ですよ。
構成変わる前は１秒で持ってきてたデータですよ。

その後、インデックスを追加したり、VIEW元のインデックスが、VIEWに反映されていないようなので、VIEWのスクリプトにヒントを追加してもらうことで、一瞬で返ってくるようになりました。
ビバ。

WHERE句の中を、絞り込める条件が先にすると早いってのは知ってたんですけど、from句の中とか知らなかったなぁ。
速さ、全然違うものなんですね。
既存のプログラムも見直したいなぁ。
まぁ、１０テーブルくらい一度に見てるので、SQL自体が悪いのかもしれませんけど。

（発行失効日等でレンジ検索になっているし、Date型をNumberに変換してたりするし。
ちなみにインデックスは、レンジ検索に向かないため、データが削除追加を繰り返すと、検索が遅くなるそうです。
データが空かどうか判定できなくて、全部見ちゃうらしい。
また、書き込み時にインデックス分の情報も作成するため、書き込みは遅くなります）

いろいろ勉強するのは楽しいなぁ。
もっと学ばなければいけません。
うん、頑張ろう。