SQLチューニングのヒント

対象RDBMSはMySQL。
2000行くらいのテーブルと10000行くらいのテーブルを結合するSQLが、実行時間が10秒くらいかかっており、これを解消しようとしてました。
で、いろいろいじってみたところ
... from hoge h left outer join fuga f on h.id = f.id and h.yyyymm = 200912
とやっていたのを、
... from hoge h left outer join fuga f on h.id = f.id and h.yyyymm = '200912'
という具合にシングルクォートで囲ってみたところ、実行時間が0.3秒と、劇的に速くなりました。
カラムyyyymmはvarchar型です。他にもいろいろいじってましたが、どうもこのシングルクォートが遅さの決め手だったと思われます。
チューニングは地道な作業ですが、これまでの経験を振り返ってみるととにかく気になることは試してみると、活路が開けるような気がします。

部分最適と全体最適

最近"部分最適と全体最適"について考えさせられることがあって、ゴールドラットの「ザ・ゴール」を思い出した。

内容についてはほとんど覚えていないけど、部分最適と全体最適という言葉は印象に残っている。あと表紙のデザインと色もインパクトがあった。
目先のことばかり気にしていると「木を見て森を見ず」になってしまうから、気をつけないと。

Google ChromeでJavaScriptをオフにする

Google ChromeのJavaScriptを無効にしようと思い、オプションの中を探してみたけれど、ない。
クッキー無効はあるけど、JavaScript無効がない。
うーん、どうすれば、、、と思ってググったら方法がありました。
http://jp.sikaku-chat.com/?eid=1136416
起動時のパラメータを指定しないといけないんだそうです。。
ちょっと面倒。でもまあ滅多に使うもんじゃないからいいかな。

「汎用性」には気をつけろ

システム開発の現場にいると、「汎用性の高い仕様でお願いします」というようなフレーズがよく出てきます。
"汎用性"という言葉は「いろいろな用途に使えて便利」というような意味で使われるが、打ち合わせなどでこの言葉が出てきたときは要注意。
無能な人間が、作るべきシステムの目的や意義が明確でない時に、この言葉を口にすることが多いからです。
"汎用性"という言葉には、ちょっとカッコよく、仕事ができそうなイメージがありますが、ほとんどの場合においてその逆で、目的を設定していない／できていないことの裏返しです。
システム開発というのは、その初期段階でシステムが果たす役割と目的を鋭く、明確にしておかないと、高確率で失敗します。
作るものがはっきりしていないとあとで作り直しになることが多く、最悪、取り返しがつかなくなることもよくあります。
なので、自分自身も"汎用性"のような曖昧な言葉はなるべく使わないようにし、またそうした言葉をよく使う人に対しては注意して付き合うのがベター。
以上、これまでの経験から得た教訓でした。

MySQLで奇数と偶数の判別

where句でこうしてやればＯＫ
■偶数
where numberColumn % 2 = 0
■奇数
where numberColumn % 2 != 0
MySQLでしか試していないけど、他のRDBMSでも使えそうです。

MySQLでフィールド値の重複をチェック

group by ... havingを使う。
こんな感じ。
SELECT id,title FROM table GROUP BY id HAVING COUNT(id) > 1;

たとえ話：Webシステムにおけるソフトとハードの関係

ソフトの不足をハードで補える、と考えている人がたまにいるけど、正直難しいと思う。
たとえるなら、ソフトは運転手で、ハードは車のような関係じゃないだろうか。
運転が下手な人(しょぼいソフト)に高性能の車(高価なハード)を与えても、加速とかハンドリングとかは車の性能で良くなるものの、"運転下手"はそのままなわけで、根本的な解決にはならない。事故に合う確率とかも、そんなに変わらないと思われます。
ところが逆の場合、たとえばF1ドライバーは高性能車はもちろん、大衆車に乗ってもその車の持つ良さを引き出し、最高のパフォーマンスを引き出すことができる。
特に今は高性能ハードが低価格で手に入る時代になっているので、投資すべきはハードよりソフトなんじゃないだろうか。
というようなことを、ふと思いました。