MySQLとは？特徴・PostgreSQLとの違い・案件単価・将来性をフリーランス視点で解説

MySQLとは｜定義と歴史

MySQLは、1995年に最初のバージョンが公開された、長い実績を持つOSSのリレーショナルデータベースです。当初はスウェーデンのMySQL ABが開発し、2008年にSun Microsystemsが買収、その後2010年にOracleがSunを買収したことで、現在はOracleが開発主体となっています。

ライセンスはGPLと商用のデュアルライセンスで、配布形態によって選択が必要になります。最新の安定版は時期によって入れ替わるため、新規構築時はMySQL公式リファレンスマニュアルで対象バージョンのサポート状況を確認するのが安全です。本記事執筆時点では8.0系の長期サポートと9系の最新リリースが並行する状況です。

DB-Engines Rankingでは、長年Oracle Database・PostgreSQLと並ぶ上位3〜4位を維持しており、Web系・SaaS・社内システムなど幅広い領域で使われています。

MySQLが普及した背景

MySQLは、LAMP（Linux／Apache／MySQL／PHP）スタックの構成要素として爆発的に普及しました。WordPress、Drupal、phpMyAdminなど、PHPエコシステムでデファクトに近い扱いを受けたことが大きく、Webサイト構築の標準DBとしてのポジションを長く保っています。

MySQLとMariaDB／Perconaの関係

Oracle買収後、ライセンスや方針への懸念から複数のフォークが生まれました。

クラウドDBの一部はMariaDB系、オンプレ系では本家MySQL／Percona系など、案件ごとにどれが採用されているか確認しておくと、運用方針がつかみやすくなります。

ミニFAQ：MySQLとMariaDBはどちらを学ぶべきか

Q. 学習の入り口としてはどちらを選ぶべきですか？

A. SQLの基本文法はほぼ共通のため、まずは案件で多く採用される方を優先するのが現実的です。日本のWeb開発・社内システムでは本家MySQLが採用される案件が多めですが、クラウド事業者によってはMariaDBが提供されることもあり、配属先の環境に合わせるのが安全です。

MySQLの主な特徴

MySQLは、シンプルさ・実績・周辺エコシステムの厚みが強みです。

①InnoDBがデフォルトのトランザクション対応

MySQL 5.5以降、InnoDBがデフォルトのストレージエンジンになりました。InnoDBは次のような機能を備えています。

• ACID準拠のトランザクション

• 外部キー制約のサポート

• MVCC（マルチバージョン同時実行制御）

• 行ロック（テーブルロックではなく行単位）

• クラッシュリカバリ

現在のMySQL案件はほぼInnoDB前提で進むため、「MySQL＝トランザクション弱い」というのは過去の話と捉えるのが実態に近いです。

②複数ストレージエンジンの選択肢

MySQLの設計思想として、テーブルごとに異なるストレージエンジンを選べる仕組みがあります。代表的なものには次があります。

実運用ではほとんどInnoDBで完結しますが、レガシー案件ではMyISAM混在のケースも残っています。

③レプリケーション機能の充実

MySQLは、レプリケーション機能の選択肢が広いことで知られています。代表的な構成は次の通りです。

• 非同期レプリケーション：マスター／レプリカ構成での標準的な方式

• 準同期レプリケーション：耐障害性を高めた構成

• グループレプリケーション：複数ノード間でデータをほぼ同期する仮想同期方式（5.7以降）。書き込み性能の水平スケールというよりは、可用性向上が主目的

• InnoDB Cluster：グループレプリケーション＋MySQL Shell＋MySQL Routerによる高可用性構成

スレーブ／レプリカへの読み取り振り分けや、クラウドのRDS／Auroraでの自動フェイルオーバーなど、運用面の選択肢が豊富です。

④クラウドDBサービスとの親和性

MySQLは、主要クラウドのマネージドDBサービスで広くサポートされています。

• AWS RDS for MySQL／Aurora MySQL

• Google Cloud SQL for MySQL

• Azure Database for MySQL

AWS Aurora MySQLは、AWS独自のストレージレイヤーで読み取りスケール・自動フェイルオーバー・ストレージ自動拡張などを実現しています。書き込みは原則1ノードが受け持つ構成のため、書き込み性能のスケールを目的とする場合は別途シャーディング等の設計が必要です。SaaSバックエンドの選択肢の一つとして採用されています。

⑤豊富な周辺ツール・教材

長い歴史と普及率の高さから、書籍・Webリソース・GUIツール（MySQL Workbench、phpMyAdmin、DBeaver等）が充実しています。学習開始時に詰まりにくく、トラブル時に検索すれば情報が見つかりやすいのは実務上の大きな利点です。

ミニFAQ：InnoDBとMyISAMはどちらを使えばよいか

Q. 新規開発でMyISAMを選ぶ場面はありますか？

A. 現在の汎用用途では基本的にInnoDB一択で問題ありません。MyISAMはトランザクション・行ロック・クラッシュリカバリに対応していないため、業務システム・Webアプリで採用する場面はほぼ残っていません。一部の全文検索・読み取り専用ログテーブルなどで例外的に使われる程度です。

MySQLとPostgreSQLの違い｜選び方の判断基準

両者ともOSSのRDBMSですが、設計思想・得意領域は異なります。PostgreSQL側の詳細はPostgreSQLとは？特徴・MySQLとの違い・案件単価・将来性をフリーランス視点で解説で整理しています。

比較表

選び分けの実務的な軸

技術的な優劣だけで決まるケースは多くなく、次のような実務的要因が判断軸になります。

• 既存スタック：チームがすでに使い慣れているDBが優先

• エコシステムとの相性：WordPress等のCMSはMySQL前提のものが多い

• ライセンスの取り回し：再配布・組み込み製品ではPostgreSQL側が扱いやすいケースがある

• クラウドサービスの選択：使いたいマネージドサービスの提供状況で選ぶ

• 必要な機能：JSON深掘り・地理情報・ベクトル検索などはPostgreSQLが先行している

「複雑クエリ・拡張性・整合性要件を重視するならPostgreSQL／既存のWeb系エコシステムやシンプルな運用を重視するならMySQL」が大まかな判断軸として参考になります。

ミニFAQ：シェアはどちらが大きいのか

Q. 国内・世界でのシェアはどちらが上ですか？

A. DB-Engines Rankingの人気度指標では、Oracle Database・MySQL・PostgreSQLが上位を占め、年や指標で順位が入れ替わる状況です。MySQLは長期的に大きなシェアを持つ一方、PostgreSQLの伸びも顕著です。シェアだけで学習投資を決めず、案件・スタック・本人のキャリアプランで選ぶのが現実的です。

MySQLが向いている案件・向いていない案件

実案件での適性を整理します。

MySQLが選ばれやすい案件タイプ

• WordPress／EC-CUBEなどのCMS案件：エコシステム上、MySQL前提のものが多い

• PHP（Laravel／CakePHP等）／Ruby on Rails／Django等の標準スタック：どのFWでもMySQLは標準サポート

• 読み取り中心のWebサービス・社内システム：シンプルな構成で運用しやすい

• 大規模Webサービスの分散構成：Vitess（MySQL分散レイヤー）、Aurora MySQLなどスケールアウト手段が豊富

• 既存スタックを継承する案件：歴史的にMySQLが採用されており、移行リスクを取らない場合

あえてPostgreSQLが選ばれやすい案件タイプ

• 複雑な分析クエリ・データ基盤：CTE・ウィンドウ関数・JSONB活用が中心

• 地理情報サービス：PostGISでGIS処理を完結させたい

• 生成AI／RAG基盤：pgvectorによるベクトル検索を組み込みたい

ここでも「常にMySQLが優れている／劣っている」という主張ではなく、案件の要件と既存資産で選ぶのが原則です。

ライセンスと商用利用の注意点

MySQLのライセンスは、自社開発・自社内利用の範囲では多くの場合GPL版で問題なく使えますが、再配布・組み込み・派生製品では注意点があります。

主な利用パターンと考え方

ライセンス解釈は事業形態・契約・各国の法解釈に依存します。再配布や組み込みを伴う場合は、必ず法務確認を行ってください。なおMySQLのデュアルライセンスを避けたい場合、MariaDB（GPLのみ・コミュニティ運営）を選ぶ選択肢もあります。

Oracle MySQL公式のライセンス情報に最新の条文・FAQが整理されています。

MySQLエンジニアの仕事内容と必要スキル

MySQLを扱うフリーランス案件は、職種ごとに求められるレイヤーが異なります。

主な職種と業務範囲

職種ごとの全体像は、データベースエンジニアとは？仕事内容から必要なスキル、年収について解説・バックエンドエンジニアとは？仕事内容や年収、必要なスキルを詳しく解説で扱っています。

スキル別の習得優先順位

MySQL案件でアサインを狙うなら、次の順序で積み上げるのが現実的です。

1. SQL基礎：DDL／DML／JOIN／集計／サブクエリ／ウィンドウ関数

2. InnoDBの理解：トランザクション分離レベル、行ロック、ギャップロック、デッドロック対処

3. インデックス設計：B-tree、複合インデックス、カーディナリティ、EXPLAINの読み方

4. 運用：mysqldump／xtrabackupによるバックアップ、レプリケーション設計、スロークエリログ

5. クラウド連携：AWS RDS for MySQL／Aurora MySQL、Cloud SQL、Azure Database

6. 周辺ツール：MySQL Workbench、phpMyAdmin、Percona Toolkit、ProxySQL

「SQLが書ける」だけでは差別化しにくく、InnoDBの内部挙動とインデックス・チューニングまで踏み込めると単価帯が上がりやすい傾向があります。

上位単価帯で求められるスキルセット

公開案件を見る限りでは、月100万円前後を超える案件では次のスキルが組み合わせで要求されるケースが目立ちます。

• 大規模MySQLの運用経験（数十億行級・シャーディング・パーティション）

• AWS Aurora MySQLでのチューニング・移行経験

• Vitess等を使った分散MySQL運用

• マイクロサービス／高トラフィックWebサービスでの設計経験

• バックエンド言語FW（PHP／Java／Go／Ruby／Python等）との組み合わせ

ここで挙げたスキル像は「該当案件を受けるための条件」であり、未経験者にいきなり要求されるものではありません。

MySQL案件の単価相場とフリーランス年収

数字は単一ソースに頼らず、複数のフリーランスエージェントの公開案件ベースで見るのが安全です。なお下記は2026年5月時点でフリコンが主要フリーランスエージェント数社（Webバックエンド・DB・データ基盤領域の公開求人）を確認した範囲での目安であり、稼働日数・商流・担当範囲・必須スキル・面談評価で大きく変動します。

公開案件ベースの単価帯

MySQLを必須・歓迎スキルに含む案件では、次のような月額単価の募集が見られます。

• よく見られる帯：月50万〜80万円程度

• 高めの募集で見られる帯：月90万〜110万円程度

• 一部の高難度・専門領域案件：月130万〜160万円超の募集もある

MySQL単独で高単価帯に届くケースはあまり多くなく、PHP／Ruby／Go／Pythonなどのバックエンド言語、クラウド（特にAWS）、設計・運用経験との組み合わせで募集されるのが一般的です。

単価帯ごとに要求されるエンジニア像

以下は公開案件で見られる募集要件をもとにした目安です。実際の単価は、稼働日数・商流・担当範囲・面談評価によって変動します。

単価相場の全体像は【2026年最新版】フリーランスエンジニアの単価相場と単価の上げ方とは？、単価交渉の進め方はフリーランスエンジニアの単価交渉のコツ｜タイミング・伝え方・根拠の作り方で扱っています。

年収の目安

上記単価帯から月額×12か月で単純換算すると、年間売上ベースでは約600万〜1,400万円程度が目安になります。ただし、案件の切れ目・稼働率・経費・税金・社会保険料を差し引いた手取りとは異なり、フリーランスでは売上＝所得ではない点に注意してください。

キャリアパスと将来性

MySQLは古くから使われている技術ですが、現在進行形で進化と需要が続いている領域です。

将来性を支える要素

• クラウドDBの主要選択肢：AWS Aurora MySQL、Cloud SQL、Azure Database for MySQLなど各クラウドが手厚くサポート

• CMS／ECサイトのインフラ：WordPressをはじめとするPHP系CMSはMySQL前提。長期的にメンテナンス需要が続く

• 大規模Webサービスでの分散実績：Vitess、Aurora、Group Replicationなどスケールアウト手段が成熟

• AI・分析との連携：dbt、AirflowなどのデータパイプラインからMySQLを参照するパターンが定着

新しさを売りにするDBではない一方、既存システムの保守・改修・移行案件が継続的に存在するため、需要は安定して見込める領域と捉えてよいでしょう。

キャリアパスの方向性

MySQLスキルからの分岐は主に3方向です。

• バックエンド／フルスタック方向：PHP・Ruby・Go・Python等のFWと組み合わせ、サービスサイドのリードへ

• DBA／SRE方向：レプリケーション設計・チューニング・大規模運用に特化し、DB専任エンジニアへ

• データエンジニア方向：MySQLをデータソースとしたDWH・ETL・分析基盤設計へ

進む方向で追加習得する周辺技術が変わるため、早めにキャリアの方向性を定めると学習投資が効率化します。

MySQL学習ロードマップ｜未経験〜実務レベル

「とは」を理解したら、次は実務レベルまでどう積むかです。期間の目安と学習順序を整理します。

Phase 1：SQL基礎（1〜2か月）

• SELECT／INSERT／UPDATE／DELETEの基本操作

• JOIN／GROUP BY／HAVING／サブクエリ

• トランザクションとロックの基本概念

SQLとは？歴史から考え方や年収まで徹底解説も学習導入に役立ちます。

Phase 2：InnoDBとMySQL固有機能（1〜2か月）

• InnoDBのトランザクション分離レベル（READ COMMITTED／REPEATABLE READの違い）

• 行ロック・ギャップロック・デッドロックの挙動

• インデックス（B-tree、複合インデックス、カバリングインデックス）

• mysqlコマンドラインクライアントの基本操作

Phase 3：パフォーマンスチューニング（2〜3か月）

• EXPLAINでクエリプランを読む

• スロークエリログ、performance_schema、sys schemaの活用

• インデックス設計の原則と検証

• 不要インデックスの棚卸し

Phase 4：運用・クラウド連携（2〜3か月）

• mysqldump／xtrabackupによる論理・物理バックアップ

• ポイントインタイムリカバリ（バイナリログの活用）

• 非同期／準同期／グループレプリケーションの理解

• AWS RDS for MySQL／Aurora MySQLの基本操作

• 監視（CloudWatch、Datadog、Percona Monitoring等）の組み込み

ここまでを既にバックエンド実務経験がある人が押さえると、月60〜80万円帯の案件要件に近づきやすくなります。未経験者や経験の浅い段階では、言語・FWスキルと組み合わせて段階的に積み上げる必要があります。

学習リソース

• MySQL公式リファレンスマニュアル（日本語）

• MySQL公式チュートリアル

• 公式のオンライントレーニング（MySQL University等）

公式ドキュメントは日本語版が整備されており、仕様確認の基準として使いやすい状態が整っています。

ケース別の選択肢｜Webアプリ／CMS／大規模Web

MySQLを使うシーン別に、注意点と組み合わせを整理します。

Webアプリのバックエンドで使う場合

• 代表的なFW：Laravel／CakePHP／Symfony／Ruby on Rails／Django／Express／NestJSなど主要FWは公式サポート

• N+1・スロークエリ対策：ORM経由のクエリは肥大化しやすく、EXPLAINでの確認が習慣化されているかが品質を分ける

• マイグレーション運用：Flyway、Liquibase、各FW標準のマイグレーション機能の使い分け

FW別の詳細はRuby on Railsとは？特徴・用途・年収・将来性をフリーランス視点で徹底解説、Laravelとは？PHPフレームワークの特徴・できること・年収・将来性をフリーランス視点で徹底解説、Djangoとは？Pythonフレームワークの特徴・用途・年収・将来性をフリーランス視点で徹底解説も参考になります。

WordPress／CMS系で使う場合

• テーブル設計の特徴：WordPressのスキーマはwp_postsを中心に汎用化されており、JOINやmetaテーブルとの結合でクエリが重くなりがち

• チューニングポイント：オブジェクトキャッシュ（Redis／Memcached）の組み合わせ、クエリの集約、不要なプラグインの整理

• マネージドホスティング：KUSANAGI、Amimoto、WP Engineなど、MySQL前提のチューニング済み環境を採用するケース

大規模Web／高トラフィックサービスで使う場合

• シャーディング・分散：Vitess、ProxySQL、独自シャーディングなど構成パターンが多様

• Aurora MySQL：高IOPS環境やマネージドな高可用性を求めるサービスで選択肢になる。書き込みノードは原則1台のため、書き込みスケールが要件の場合は別途設計が必要

• 読み取り分散：レプリカへの読み取り振り分け、リーダーラグの監視・許容範囲設計

よくある失敗パターンと対策

実務でMySQL案件に入ったときに詰まりやすいポイントを、対策とあわせて整理します。

失敗1：文字コードの混乱

MySQLでは文字コード設定がDB／テーブル／カラム／接続の各レイヤーに存在し、設定の食い違いで文字化けや絵文字格納失敗が起きやすいポイントです。

• 対策：新規構築時はutf8mb4（4バイト・絵文字対応）に統一。旧来のutf8（3バイト）との違いを意識し、接続設定でも明示する

失敗2：暗黙の型変換による性能劣化

INT型カラムに文字列で比較すると、暗黙の型変換でインデックスが使われずフルスキャンになることがあります。

• 対策：アプリ側のSQL生成時にカラム型と一致した値を渡す。EXPLAINでtypeがALL（フルスキャン）になっていないか確認

失敗3：トランザクション分離レベルの誤解

MySQLのデフォルト分離レベルはREPEATABLE READで、ファントムリードの挙動などPostgreSQLや他DBと異なる挙動があります。

• 対策：分離レベルの違いを正確に把握し、ロック・ファントム関連の不具合を再現テストで検証する

失敗4：レプリカ遅延を監視していない

非同期レプリケーション環境で、レプリカが書き込みに追いつかず古いデータが返ってしまうケースがあります。

• 対策：SHOW SLAVE STATUS（8.0以降はSHOW REPLICA STATUS）のSeconds_Behind_Source／Seconds_Behind_Masterを監視・アラート化。読み取り遅延を許容する設計を入れる

失敗5：mysqldump任せのバックアップで巨大DBに対応できない

数百GB級のDBになると、mysqldumpでは取得・復元に長時間かかり、運用に支障が出ます。

• 対策：xtrabackupやAurora／RDSのスナップショットを併用。PITRが必要ならバイナリログ運用を組み込む

これらは案件冒頭の1〜2週間で確認することで、信頼を得やすい論点です。

まとめ

MySQLは、Webアプリケーション・CMS・大規模Webスケールまでをカバーする、長年の実績を持つOSSデータベースです。フリーランスエンジニアにとっては、案件で要件に含まれる頻度が高く、バックエンド・DBA・SREのいずれの方向にも展開できる軸の1つになります。

• InnoDBがデフォルトのトランザクション対応エンジン

• ライセンスはGPL／商用デュアル。再配布・組み込みでは法務確認が必要

• PostgreSQLとの選び分けは技術的優劣ではなく、ワークロード・既存スタック・運用体制で決まる

• 案件単価はよく見られる帯で月50万〜80万円、高めの帯で月90万〜110万円程度。クラウド／FW／チューニング経験との組み合わせで上振れしやすい

• 学習はSQL基礎→InnoDB／インデックス→チューニング→運用／クラウドの順

次のアクションは、自分の現在地に合わせて1つ選んでください。

• 未経験〜SQL初学者 → 公式チュートリアル＋SQLとは？歴史から考え方や年収まで徹底解説から

• バックエンド経験あり、MySQL深掘り → InnoDB／インデックス／EXPLAINから

• 実務経験あり、案件単価を上げたい → Aurora MySQL／分散構成／レプリケーション設計を検討

案件選びで迷ったら、フリコンの担当者へ相談すると、現在の市況・公開案件・求められるスキルを踏まえた提案が受けられます。

参考リンク

• MySQL公式サイト

• MySQL公式リファレンスマニュアル（日本語）

• Oracle MySQLライセンス情報

• MariaDB公式サイト