第8回（最終回）　まとめ――SQLから逃げない！

　本記事は、『Software Design 2019年8月号』の第2特集「ゲームを題材に学ぶ内部構造から理解するMySQL」をWeb掲載用に再編集したものです。
　本記事のテーマを、より基本的なところから丁寧に解説した『SQLの苦手を克服する本　データの操作がイメージできれば誰でもできる』が2019年8月26日に発売されました。本記事と併せてご活用ください。

SQLはボトルネックか？

　筆者はチューニングの仕事に携わることが多いのですが、その経験からシステムで一番ボトルネックになりやすいのがRDBMS（SQL）だと断言できます。筆者の20年以上のキャリアの中で、途中で廃れてしまったり、流行りだしたりといった言語は数知れずあります。しかし、SQLは使われ続けていますから、SQLが最も息が長いと言えますし、今でも一番シェアが高いと言えるでしょう。それにもかかわらず、SQLの理解は進んでいません。むしろ、優れたORMが次々に生まれているせいか、年を追うごとに多くのエンジニアのSQLへの理解が後退しているようにすら感じています。

SQLの勉強のしかた

　Software Design 2017年11月号の第1特集「SQL50本ノック」を執筆された㈱リブセンスでは、エンジニアではない全営業職員が勉強会を通じてSQLを習得し、利用されているそうです（https://www.slideshare.net/livesense/150225-sql-foreveryone-45695818⁠）⁠。それほど簡単なものであるSQLをエンジニアが習得できないというはずがありません。普段使っているオブジェクト指向言語という代替手段があるため、安易に「SQLから逃げている」だけでしょう。エンジニアがシステムで使われている技術から逃げるべきではないですから、ぜひ、勉強のしかたを改めてください。

　SQLにはオブジェクト指向言語とはまったく違う、2つの勉強のしかたがあります。

集合のイメージを持つ

　1つは、SQLをイメージで考えるということです。SQL以外の言語はメソッド単位でフローチャートになります。このフローチャートのイメージはプログラミングの基本中の基本です。ある言語でフローチャートがイメージできるようになれば、ほかの言語に移行するときは主要な文法を覚えれば問題ありません。しかし、SQLはフローチャートでは表現できませんから、文法を覚えるだけでは理解できません。これがいくつかの言語を経験したエンジニアがはまるポイントでしょう。

　SQLはフローチャートなどオブジェクト指向言語で使えたイメージとは違う「集合のイメージ」を持つ必要があります。「⁠集合のイメージ」なしにSQLの構文を書くと、オブジェクト指向言語でいうところの、フローチャートのイメージができない新人プログラマが書いたスパゲッティプログラムのようなコードになってしまいます。そんなSQLはほかの開発者は読めないでしょう。ですから、まずはSQL特有の「集合のイメージ」のしかたを身に着けることです。

SQLの内部処理を考える

　もう1つは、実は筆者が若いころにとった勉強方法です。それは、「⁠自分がオプティマイザーを作るとしたらどう作るか、SQLの仕様策定チームにどう依頼を出すか」と想像し、実行計画とSQLを見比べながらコーディングすることでした。現在であれば、MySQLはソースが公開されているわけですから、そのソースを解析すれば筆者より早く理解できるでしょう。

　この勉強の方法は確実で、かつ深く理解できますが、非常に効率が悪いです。ですから、まずは「集合のイメージ」を持ってSQLを書く癖を付け、さらに実行計画とSQLとを見比べることを繰り返せば、早く、そして深く理解できるようになるでしょう。このSQLのイメージのしかたについては、2019年8月に発刊される拙著『SQLの苦手を克服する本』で詳しく解説していますので、ご一読いただければ幸いです。

ORMの流行り廃り

　ORMの流行り廃りはこの20年間で何度も起こりました。20年間を振り返り、流行り廃りを検証すると、

ハードウェアの性能が上がる

ORMの完成度が上がる

要件が変わる（たとえばビッグデータの活用など）

のバランスで要件が厳しくなれば、「⁠SQLを書かないとね」となり、ハードウェアやORMの性能が上がれば、「⁠SQLなんて知らなくてもいい」となってきました。この20年間で、ORMの流行り廃りが何度も起きた理由は、バランスが何度も崩れているからでしょう。

　本連載では、実行計画をJavaのようなソースに直して表現するということを行いました。実際に、SQLはオブジェクト指向言語に似たソースに直されてから実行されています。つまり、気づいた方もいらっしゃるかもしれませんが、SQLでできることをオブジェクト指向言語を用いて実現することは、“⁠車輪の再開発⁠”にすぎません。現在では、Ruby on Railsなどで使われるActiveRecordのように「ORMとしては」たいへん優れているものがありますが、どんなに優れていても、ORMは「⁠“⁠車輪の再開発⁠”をお手伝いするためのもの」ですから、本質的な解にはなり得ません。そのため要件が厳しくなれば、「⁠SQLを書かないとね」が復活してくるわけです。

SQLから逃げない

　「⁠（⁠車輪の再開発になっても）ORMが良い」というエンジニアの主張は、裏を返せば、「⁠SQLが嫌い（わかりにくい⁠）⁠」というものになりますが、それは「SQLが苦手なエンジニア」による主観であり、主観を除けば、

SQLを書く

HandlerSocketなどを用いてSQLをショートカットする

NoSQLを使う

のいずれかが合理的な結論になるはずです。

　読者の中にも、今、まさに「そうは言ってもSQLは嫌い」と思っている方がいらっしゃるのではないでしょうか。得意な言語では、「⁠ユーザには体感できない」レベルの精度で効率化を目指す優秀なエンジニアであっても、SQLを使うかの議論をするとき「SQLが嫌い（わかりにくい⁠）⁠」という主観が入ることがあまりにも多いです。

　その主観でSQLを避けた結果、「⁠ユーザが体感する」どころか、イライラしてゲームをアンインストールさせてしまうほどのパフォーマンスの低下が起きたり、ランニングコストが数倍になったり、「⁠同時対戦をやめる」といったゲームの本質的な価値を変えてしまうことが起きたりする、ということを本稿の中で解説させていただきました。

　これらは、ゲームに限らず業務システムでも起きています。これは、エンジニアとして、「⁠SQLが嫌い（わかりにくい⁠）⁠」という主観とトレードオフして良い内容ではないはずです。どうかSQLから逃げずにSQLの苦手を克服してください。