「JOINはDBサーバの負荷が高くなる」は本当か？

　「⁠JOINは複雑なので，単純なSQLに分割してぐるぐる系で取得すれば，処理が遅くなったとしても，DBサーバの負荷は減る」と考えているエンジニアが実際に存在します。前回解説したとおり，SQLのオーバーヘッドの大きさをイメージできれば，「⁠そんなことはない」と理解できたかもしれませんが，さらに深く理解するために，本稿ではJOINを分割したときと，JOINしたときの違いを見てみましょう。

　JOINした（一発系の）リスト1を手続き型言語に直してみると，リスト2になります。

SELECT *
FROM country
INNER JOIN city
ON country.Code = city.CountryCode;

for(Row rowCountry:country){
    rowKeys = city.Indices.CountryCode.getRangeKeys(rowCountry.code);
    for(RowID rowID:rowKeys){
        // SELECT句の処理があれば行う
        retRows.add(rowCountry, city.getRow(rowID));
    }
}
// ORDER BY句があればソート
return retRows;

　ぐるぐる系のリスト3を手続き型言語に直してみると，リスト4になります。

SELECT * FROM country;
-- 以下をcountryの件数回問合せる
SELECT * FROM city WHERE CountryCode = ?;

for(Row rowCountry:country){
    retRows.add(rowCountry);
}
return retRows;

// APサーバからcountryの件数回呼び出される
rowKeys = city.Indices.CountryCode.getRangeKeys(?);
for(RowID rowID:rowKeys){
    retRows.add(rowCountry, city.getRow(rowID));
}
return retRows;

　見比べてみると，「⁠ぐるぐる系」でも，DBサーバの処理は何ひとつ減っていないことがわかります。

　第4回の図2と第3回の「DBエンジンがSQL実行前に行う内部処理」をもう一度見てください。ぐるぐる系は，この膨大なSQLのオーバーヘッドとネットワークの処理が無駄に繰り返されるため，DBサーバの負荷を下げるどころか，負荷を大幅に上げることになるのです。

APサーバで肩代わりできる処理

　APサーバで処理することによってDBサーバの負荷が下がるということは，APサーバがDBサーバの処理を肩代わりしているということになります。APサーバで肩代わりできる処理は次のものしかありません。

• マスタ類のキャッシュ → APサーバの同期が取れれば有効
• SELECT句の処理 → SELECT句でソートするWindow関数以外は誤差
• ループのブレイク処理 → 誤差
• ソート処理 → DBサーバの負荷を下げるには有効

　DBサーバの負荷をどうしても下げたいのであれば，SQLでのORDER BYを禁止にすべきですが，ほとんどの共通仕様やコーディングルールで，「⁠ORDER BYを必ず付けること」となっています。ORDER BY（ソート）は「1ページにつき10件ずつ表示する」といった表示件数を制御するページングが必要なWebシステムでは意味がありますが，そうでなければAPサーバでソートしても問題はありません。ソートは非常に重い処理ですので，シングルポイントになるDBサーバで処理するより，分散できるAPサーバで処理するほうが良いでしょう。

SQLでどこまで処理すべきか

　C言語やアセンブリ言語の経験がないエンジニアが増えています。そのため，CPUとメモリの関係をあまり意識することがなくなっています。ここでは，CPUやメモリを意識してSQLについて考えてみましょう。

　SQLはRDBMSのインプロセスで動作します。インプロセスとはRDBMSのメモリ空間内で処理されるという意味で，ポインタ（メモリのどこにデータがあるかを示すもの）で処理できます。C言語（C++）の経験がなければ「参照渡しできる」と読み替えても良いでしょう。APサーバは別のメモリ空間で動作しています。APサーバから見れば，RDBMSのメモリ空間のデータを直接読み書きすることはできませんから，お互いに値渡しするしかありません。

　ここで第1回の図1で解説したページ単位でのI/Oを思い出してください。インプロセスであればポインタ（参照渡し）で処理できる内容でも，APサーバで処理させるためにはDBサーバはデータをバッファからワークメモリにコピーして，レコード，フィールドに加工しなければなりません。つまり，「⁠できる限りSQLで処理するほうがDBサーバの負荷が下がる」というのは，「⁠DBサーバから大量のデータをAPサーバにすべて値渡しして処理するより，DBサーバ内でできる処理は参照渡しで処理するほうが効率が良い」と考えれば理解しやすいのではないでしょうか。SQLのオーバーヘッドの繰り返しを避けるだけでなく，内部処理もSQLのほうが効率的になるわけです。

　設計時に「SQLでどこまで処理するか」を決めるには，処理全体を自分が得意な手続き型言語で設計し，「⁠どのメモリ空間で処理すべきか，ネットワークを越えて値渡しで処理することで効率的になる処理は何か？」と切り分けて考えてみましょう。そうすると，APサーバが肩代わりできる処理は前述の4つしかないことが理解できるはずです。ですから，ほとんどの場合，「⁠SQLでどこまで処理すべきか」というのは，「⁠ソート以外のデータに関連する処理はすべてSQLで処理すべき」となります。

　「⁠そんな極端な」という声が聞こえそうですが，DBサーバで利用される言語がSQLではなくAPサーバと同じ言語であったなら，「⁠APサーバで処理すべき」と考えるエンジニアは少ないはずです。SQLになったときに逆の判断になる理由は，合理的に判断した結果でしょうか？　「⁠SQLが嫌い（わかりにくい⁠）⁠」という主観が影響してはいませんか？