キャッシュを無駄遣いしないようにクエリを書く：真・Dr. K's SQL Serverチューニング研修（6）（3/3 ページ）

後からのチューニングには想像を絶する苦労が

　このように、クエリの実行プランを調べて、チューニングした後で、パラメータ化クエリに転換していくのです。パラメータ化クエリにすると言っても、データ長が違うだけ、あるいはデータベースの指定方法が違うだけの、別個のパラメータ化クエリになっていないかということに気を付けなければなりません。そして、使用頻度の高いクエリはストアドプロシージャにしていきます。

　ただし、ストアドプロシージャにすればどんなものでもよいというわけでもありません。よく調べると、テーブルを作るDDL（Data Definition Language）が入っていることがあります。こういうストアドプロシージャは、実行するたびにリコンパイルとなってしまうので、テーブルを作る部分だけ関数として外に出すなどの手を考えると良いでしょう。

　私は、すでにあるシステムを後から調べて、この手順でチューニングするということを何度も経験してきましたが、実に骨の折れる作業です。できることなら、システムを作る段階から、こういうことを意識して、最適なクエリを作っていくべきです。

ものづくりの姿勢を見直すべし

　最近は、データベースを利用するアプリケーションを作る人たちの考え方が、タイムトゥマーケット、つまり市場の速い動きについていくために、短期間でシステムを作ってしまえという方向に流れているように感じます。

　短期間でシステムを作ると、どうしても準備期間が取れず、あちこちに無理がかかります。完成したシステムを見ると、とんでもないクエリを使っているものがたくさんあります。解説書にあるクエリをちょっと変えただけのようなものなど、その場しのぎで作ったクエリがたくさん見つかるのです。

　こういうシステムができてしまう背景には、開発期間の短さという問題もありますが、私は開発者のスキルの問題もあると考えます。リレーショナルデータベースの基礎となるの集合理論を習得していない開発者があまりに多いのです。

　私が、システム構築に最初からかかわるプロジェクトでは、基本設計に時間をかけます。最初に、システムがどんな業務にかかわるのかをしっかり把握します。業務を十分に理解したところで、テーブル設計と入出力設計をします。

　ER図とDFD（Data Flow Diagram：データフロー図）ができたら、合宿に入って、カラムの抜けのチェックや、SQL Serverの構造に照らして、最適なインデックスの張り方を考えたり、バッチ処理にかかる時間を精密に計算するなどの作業を一気にやってしまいます。

　バッチ処理や、バックアップ、リストアにかかる時間の見積もりは、失敗すると業務に支障をきたすおそれがあるので、正確に見積もらなければなりません。例えば、バッチ処理にも、日次の売上集計だけでなく、月次の集計、年次の集計など、集計期間によっていくつものバッチ処理があります。

　そして、それらのバッチ処理がすべて重なる日がどうしてもできます。そのような日でもすべてのバッチ処理を済ませ、バックアップ、リストアに必要な時間を残して、きちんと業務を続けられるようにしなければならないので責任重大です。だからこそ、事前に時間をかけてしっかりと設計をしなければならないのです。

　そして、設計の段階でクエリのチューニングも済ませてしまいます。このとき、使用頻度の高いクエリのチューニングは、最も腕が立つ開発者に任せます。すでにあるシステムを調べて、使用頻度の高いクエリを探してチューニングしていくよりも、少ない労力で、確実に性能を発揮するクエリを作れます。

　こうして、きちんとチューニングして、ストアドプロシージャにしていくことで安定した性能を発揮するシステムができるのです。これだけのことをやらないとよいシステムはできません。

　要件定義、基本設計に時間をかけて、力を入れて、手戻りをさせない。先にお話しした集合理論の問題なども含めて、これから私は、きちんとシステムを作れる人を育てていきたいと強く願っています。