きのうのブログで、実際のデータ量で流したら、データベースが遅いというときの話をかきましたが、「じゃあ、どうするの？」というのを書いてなかったので、そのまとめ。
情報処理試験のデータベーススペシャリストに、いちおう受かっているウィリアムのいたずらがお送りする、「データベースの処理が遅いときの改善法」
| プログラムをいじらない場合：早くなるかどうかわかんないけど、やってみる？ |
|---|
（１）データ領域を整理する
VACCUM FULLしてみる
（２）もう一度テーブルをつくって、データをいれなおしてみる
一度データをいっぱい入れちゃって、インデックスなんかがおかしくなっていたり、壊れていたりして遅くなったときは、意味ある。
（３）インデックスの置き場所を変える
汎用コンピューターや富士通のしんふぉなんかだと、インデックスの置き場が指定できる。この場合、インデックスのアクセス回数を減らすと（汎用機の場合は、トラック、シリンダ指定ができるので、その指定を使って、できるだけ、シークを減らすようにするらしい。詳しくは知らん）改善される、こともある。
（４）あんまり効果ない場合がおおいけど、メモリをつむっていうので、解決しちゃうこともある
（５）ＤＢのパラメータをいじってみる
| ・プログラムをいじらない場合：早くなること多し |
|---|
（６）インデックスをつけて、検索条件を、インデックスで処理できるようにする。
（７）インデックスをハッシュテーブルにしてしまう
（８）シーケンシャルアクセスが、頻繁にあり、更新がないマスタ系の場合、
（オラクルでないとできないかと思うが）ネイティブシーケンスを、シーケンシャル順にすると、早く出来るらしい（聞いたことがあるというだけの話、やったことはないので、詳しくは知らん）
（９）（危険だけど）参照制約とかをはずすと、早くなることも。。。
| ・プログラムをいじる：いじる範囲が小規模順 |
|---|
（１０）Javaの場合、ガベージコレクション（System.gc())を、ある程度のまとまりごとに（System.gc()を書いて）強制的に行う。
→効果ないことも、多い。
（１１）テーブルアクセスをメモリーアクセスに変える
更新があったら、テーブルと同時にメモリも書き換え、普段の検索は、メモリから結果を返すようにする。とくに、クライアントサーバーで、クライアント側で返せるようにすると、効果絶大だが、問題は、更新があったとこを、どうやって知るか・・・
（１２）テーブルアクセスを、ファイルアクセスなどに変える
夜間バッチなど、自分しか、そのテーブルにアクセスしていないことが確実な場合は、なにもデータベースをアクセスする必要はなく、必要なデータをファイルに書き出し、ファイル操作を行い、結果をＤＢに返す（更新する）という形もとれる。
（１３）Ｖｉｅｗを作成する
ＶＩＥＷはよくない、問題を起こしやすいと、佐藤正美氏は提唱している。
しかし、複数テーブルのJoinなどでは、Viewさえつくれば、一発！っていうケースも多数ある。そういうときは、Viewに変えるのもいいと思う。
つまり、Viewは、２階から飛び降りるようなもんだ。
普段は２階から飛び降りることはしない。
でも、火の手が上がっていて、飛び降りないと助からないとき、２階なら、無傷ではないかもしれないが、死なない確率も高い。そんなときは、飛び降りるだろう。それと、おんなじようなもんっす。
（１４）アクセス方法を全面的に変える
毎回全データ読んでいたのを、今回更新されたものしか読まない（履歴は取っておく）など、プログラムを全面的に見直し、かえる。
こんな、かんじかな
