[Java] 脱・全自動？Springで「MyBatis」を使ってSQLを自在に操る方法
山崎講師こんにちは。ゆうせいです。
前回は、魔法のようにSQLを自動生成してくれる「JPA」についてお話ししましたね。
「SQLを書かなくていいなんて最高！」と思った方も多いのではないでしょうか？
しかし、実際の開発現場に出ると、こんな声を聞くことがあります。
「JPAだと、複雑な検索が遅すぎる…」
「もっと細かいチューニングがしたいのに、勝手にSQLを作られると困る！」
そんなときに颯爽と登場するのが、今回紹介する MyBatis（マイバティス） です。
JPAが「全自動運転の車」だとしたら、MyBatisは「マニュアル運転のスポーツカー」のような存在です。
今回は、Spring Frameworkで愛され続けるこのMyBatisについて、JPAとの違いを明確にしながら解説していきます。
MyBatisとは？
MyBatisは、データベースとJavaをつなぐフレームワークの一つです。
JPAと同じく「O/Rマッパー（オブジェクトとリレーショナルの橋渡し役）」の仲間として扱われることが多いですが、厳密には少し性格が異なります。
MyBatisは、しばしば 「SQLマッパー」 と呼ばれます。
JPAは「Javaの命令をSQLに翻訳してあげるよ」というスタンスでしたが、MyBatisは「SQLはあなたが書いてね。でも、実行結果をJavaのオブジェクトに詰め替える面倒な作業はやってあげるよ」というスタンスなのです。
つまり、「SQLを書く自由」をプログラマーに残してくれる のが最大の特徴です。
JPAとMyBatisの決定的な違い
初心者の方が一番迷うのが、「結局、どっちを使えばいいの？」という点ですよね。
二つの違いを、身近な「引っ越し」で例えてみましょう。
JPA（おまかせパック）
引っ越し業者に「この家の中身を全部、新しい家に運んで」と頼むプランです。
業者が勝手にダンボールに詰め（SQL生成）、トラックで運び、新居に配置してくれます。
楽ちんですが、「この大事な皿は、新聞紙じゃなくてタオルで包んでほしい」といった細かい指定をするのは少し大変です。
MyBatis（自分で梱包プラン）
ダンボールへの箱詰め（SQL記述）は、すべて自分で行います。
業者は「詰め終わったダンボールを運ぶ（実行とマッピング）」だけを手伝ってくれます。
手間はかかりますが、「ここは厳重に」「ここは適当でいい」といったコントロールが自由自在です。
機能比較
わかりやすく表で整理してみましょう。
| 項目 | Spring Data JPA | MyBatis |
| SQLの記述 | 基本的に書かない（自動生成） | 自分で書く（必須） |
| 難易度 | 簡単な処理なら超簡単 | SQLの知識が必要 |
| パフォーマンス | 自動生成のため、最適化が難しい場合がある | 自分で書くため、高速化（チューニング）しやすい |
| 向いている場面 | 単純な保存・更新が多いアプリ | 複雑な検索や帳票出力が多いアプリ |
MyBatisの使い方（コードのイメージ）
では、SpringでMyBatisを使うとどうなるのか、実際の雰囲気を見てみましょう。
MyBatisでは、Javaの「インターフェース」と、SQLを書く「XMLファイル」の2つを使います。
1. Java側（Mapperインターフェース）
まず、「このメソッドを呼んだらSQLを実行したい」という定義を書きます。これを Mapper（マッパー） と呼びます。
@Mapper
public interface UserMapper {
// ユーザーIDを使って、ユーザー情報を1件取得したい
User findById(int id);
}
2. XML側（SQLを書く場所）
次に、上記のメソッドが呼ばれたときに実行するSQLを書きます。ここがMyBatisの真骨頂です。
<mapper namespace="com.example.UserMapper">
<select id="findById" resultType="com.example.User">
SELECT
id,
name,
email
FROM
users
WHERE
id = #{id}
</select>
</mapper>
ご覧ください。ガッツリと SELECT 文を書いていますよね？
「Javaのコードの中にSQLが混ざる」のではなく、「XMLという別のファイルにSQLを隔離できる」のがポイントです。
これにより、JavaエンジニアはJavaに集中し、DBエンジニアはXMLのSQLに集中する、といった分業もしやすくなります。
メリットとデメリット
現場でMyBatisを採用するかどうかの判断基準になる、メリットとデメリットを見ていきましょう。
メリット
- 複雑なSQLも自由自在「3つのテーブルを結合して、特定の条件で集計して…」といった複雑な処理も、SQLさえ書ければそのまま実行できます。JPAでこれをやろうとすると、非常に難解な設定が必要になることがあります。
- SQLのチューニングができる「この検索が遅いから、ヒント句を追加して高速化しよう」といった、データベース特有の細かい調整が可能です。大規模なサービスでは、これが命取りになることもあります。
- SQLの知識がそのまま活きるJPA特有のルールを覚えなくても、標準的なSQLを知っていればすぐに使いこなせます。
デメリット
- 書く量が多い（面倒くさい）単純な「保存（INSERT）」や「全件取得（SELECT ALL）」であっても、いちいちXMLにSQLを書かなければなりません。テーブル項目が50個あったら、50個分書く必要があります。
- コンパイルエラーになりにくいSQLを文字列（XML）として書くため、もしスペルミスをしていても、Javaのコンパイル時点では気づけません。実際に動かして初めて「エラーだ！」と気づくことになります。
今後の学習の指針
いかがでしたか？
「JPAがあればSQLなんていらない」と思っていた方も、「やっぱりSQLの知識は大事なんだな」と感じていただけたのではないでしょうか。
日本国内の開発現場（特に業務システムや大規模システム）では、MyBatisの採用率は依然として非常に高い です。
そのため、新人エンジニアとしては、JPAとMyBatisの両方を使えるようになっておくのが理想です。
これからの学習ステップとして、以下をおすすめします。
- SQLを復習するMyBatisを使うには、SQLが書けなければ始まりません。SELECT, INSERT, UPDATE, DELETE の基本はもちろん、JOIN（テーブル結合）についても理解を深めましょう。
- MyBatisで検索アプリを作る前回JPAで作ったアプリを、今度はMyBatisで書き換えてみてください。「自分でSQLを書く安心感」と「面倒くささ」の両方を体感することが大切です。
- 動的SQL（Dynamic SQL）を知るMyBatisには「もし検索条件に名前が入っていたら、WHERE句を追加する」といった、SQLをプログラムのように変化させる機能があります。これが使えると、MyBatisがもっと楽しくなります。
「自動のJPA」と「手動のMyBatis」。
適材適所で使い分けられるエンジニアを目指して、まずはSQLの海に飛び込んでみましょう！
それでは、また次の記事でお会いしましょう。
セイ・コンサルティング・グループの新人エンジニア研修のメニューへのリンク
投稿者プロフィール
- 代表取締役
-
セイ・コンサルティング・グループ株式会社代表取締役。
岐阜県出身。
2000年創業、2004年会社設立。
IT企業向け人材育成研修歴業界歴20年以上。
すべての無駄を省いた費用対効果の高い「筋肉質」な研修を提供します！
この記事に間違い等ありましたらぜひお知らせください。
