フクの非日常

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

DB チューニング

DBはチューニングが命である。
と、偉そうなことを言ってしまったが、チューニングを実際にやったことはない。
でも、ジョブの実行時間があまりにも遅い場合は時間的要件を満たさないことがあり、
システムとして致命的な欠陥になる。
チューニングができてこそ、DBスペシャリストの価値があるのではなかろうか。

いつお鉢が回ってくるかわからないので、基本は押さえておこう。
DBの性能を上げるにはいくつもの手段がある。
SQL文の考慮、テーブルに冗長性を持たせる、アクセスするDBを分ける、
サーバー側に処理を持たせるストアドプロシージャを利用する。などなど。

まずは基本の「き」である、SQLをどこまでチューニングできるかを実感するべし。
SQLでチューニングといえば、インデックス。
インデックスは普通に使われてるんで、逆に知らないと困るといえましょう。
インデックスを付けるのは主キーや、外部キー、ORDER BY句の列など。
しかし、
 ・テーブル行数が少ないもの
 ・列が取りうる値の種類が少ない
 ・頻繁に更新されるテーブル
などには設定しても効果が無いか、逆に性能が落ちる場合があるので注意が必要。
WHERE句の書き方によっては、インデックスは使われず、全件検索が走るのでご用心。
左辺に式を書いた場合(WHERE 単価*1.05 >1000)など、全件であるよ。

ところで、以前から疑問に思っていることを一つ。

 WHERE句の条件式は、左右をひっくり返したり、
 ANDやORで条件をつなげる順序は、実行結果に影響があるのか?

テーブルをつなぐ条件式を書くときって、T1.商品名=T2.商品名
なんて書くんだけれど、左右が逆になっても良いのかという疑問である。
結果は同じなんだろうな、というのが今の見解。
速度に差がでるのかは、いまだ疑問。実はチューニングで考慮すべきかもしれない。


コメント


管理者にだけ表示を許可する
 

 

トラックバック

上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。