1|2|3後からのチューニングには想像を絶する苦労がこのように、クエリの実行プランを調べて、チューニングした後で、パラメータ化クエリに転換していくのです。パラメータ化クエリにすると言っても、データ長が違うだけ、あるいはデータベースの指定方法が違うだけの、別個のパラメータ化クエリになっていないかということに気を付けなければなりません。使用頻度の高いクエリはストアドプロシージャにしていきます。ストアドプロシージャにすればどんなものでもよいというわけでもありません。Language)が入っていることがあります。いうストアドプロシージャは、実行するたびにリコンパイルとなってしまうので、テーブルを作る部分だけ関数として外に出すなどの手を考えると良いでしょう。私は、すでにあるシステムを後から調べて、この手順でチューニングするということを何度も経験してきましたが、実に骨の折れる作業です。できることなら、システムを作る段階から、こういうことを意識して、最適なクエリを作っていくべきです。ものづくりの姿勢を見直すべし最近は、データベースを利用するアプリケーションを作る人たちの考え方が、タイムトゥマーケット、つまり市場の速い動きについていくために、短期間でシステムを作ってしまえという方向に流れているように感じます。短期間でシステムを作ると、どうしても準備期間が取れず、あちこちに無理がかかります。完成したシステムを見ると、とんでもないクエリを使っているものがたくさんあります。解説書にあるクエリをちょっと変えただけのようなものなど、その場しのぎで作ったクエリがたくさん見つかるのです。いうシステムができてしまう背景には、開発期間の短さという問題もありますが、私は開発者のスキルの問題もあると考えます。リレーショナルデータベースの基礎となるの集合理論を習得していない開発者があまりに多いのです。私が、システム構築に最初からかかわるプロジェクトでは、基本設計に時間をかけます。最初に、システムがどんな業務にかかわるのかをしっかり把握します。業務を十分に理解したところで、テーブル設計と入出力設計をします。Serverの構造に照らして、最適なインデックスの張り方を考えたり、バッチ処理にかかる時間を精密に計算するなどの作業を一気にやってしまいます。バッチ処理や、バックアップ、リストアにかかる時間の見積もりは、失敗すると業務に支障をきたすおそれがあるので、正確に見積もらなければなりません。バッチ処理にも、日次の売上集計だけでなく、月次の集計、年次の集計など、集計期間によっていくつものバッチ処理があります。それらのバッチ処理がすべて重なる日がどうしてもできます。そのような日でもすべてのバッチ処理を済ませ、バックアップ、リストアに必要な時間を残して、きちんと業務を続けられるようにしなければならないので責任重大です。事前に時間をかけてしっかりと設計をしなければならないのです。設計の段階でクエリのチューニングも済ませてしまいます。このとき、使用頻度の高いクエリのチューニングは、最も腕が立つ開発者に任せます。あるシステムを調べて、使用頻度の高いクエリを探してチューニングしていくよりも、少ない労力で、確実に性能を発揮するクエリを作れます。して、きちんとチューニングして、ストアドプロシージャにしていくことで安定した性能を発揮するシステムができるのです。時間をかけて、力を入れて、手戻りをさせない。ゆきお)技術フェロー特別役員メインフレーム環境で20年近くデータベース関連のITプロジェクトを数多く経験。1979年から1983年まで米国に駐在し、データ主導型システム設計を実プロジェクトで学ぶ。2000までシステム構築、教育にかかわってきた。Server(2007年4月から)。