STRAIGHT_JOIN

昨日の理論から学ぶデータベース実践入門 読書会で、参加していたきむらさんから教わったのが、MySQL の STRAIGHT_JOIN なるチューニングヒント。

ミックさんが書籍やClubDB2 で言われてたけど、RDBでビッグデータ扱ってると、データ量増加に伴いある日突然実行計画が変わり、クエリが劇遅になってしまうという悪夢の症状。これ地震と違ってなんの前触れもなく、ある日いきなり訪れるだけにタチ悪すぎる。これを回避するにはオプティマイザに任せるのじゃなく、ぐるぐる系*1で対処するしかない！とのことだそうです。

読書会では某氏が、MySQL のオプティマイザの最適化はゴミ！と断言してましたが、そうなんですかね？(汗) ただし MySQL にはテーブルを Joinした順に実行するチューニングヒントがあるそうで、それが最初に述べた STRAIGHT_JOIN。MySQL 5.6 日本語リファレンスマニュアルの「Join 構文」の項には以下のように書かれています。

STRAIGHT_JOIN は、左側のテーブルが常に右側のテーブルの前に読み取られる点を除き、JOIN と同じです。これは、結合オプティマイザがテーブルを間違った順序で配置する (数少ない) 場合に使用できます

これ使えばクエリが JOIN した順に結合するので、どれほどデータ量が増えようと実行計画が変わらないとのこと。データ増えると駆動票と内部表が入れ替わり急にパフォーマンス落ちる場合があるので、これ使ってみるのもいいかも知れないなーと思った次第です。でも書いたとおりに結合するため、実行計画をかなり意識しながらクエリを書く必要はありますね。

SQL実践入門──高速でわかりやすいクエリの書き方 (WEB+DB PRESS plus)

*1:いわゆるループ