まえがき
MySQLとOracleについてChatGPTのDeep Researchで調査しました。
1. 機能・性能の違い
トランザクション管理
OracleとMySQL (InnoDBエンジン) はいずれもACID特性を備えていますが、デフォルト動作に違いがあります。OracleではAUTOCOMMITがオフであり、明示的にCOMMITするまではトランザクションが継続します。一方、MySQLはデフォルトでAUTOCOMMITオンのため各SQL文が自動コミットされ、明示的にSTART TRANSACTIONしない限り逐次確定します (
[1]
)。またOracleはマルチバージョン同時実行制御により読み取り一貫性を保証し、他トランザクションの未コミット変更(ダーティリード)を防ぎます (
[1]
)。InnoDBストレージエンジン利用時のMySQLもリードコミットやリピート可能リードで一貫性を保ちダーティリードを防ぎますが、デフォルトの分離レベルはOracle（既定: Read Committed）と異なりRepeatable Readとなっています (
[2]
)。ロック機構にも違いがあり、Oracleは常に行レベルロックでテーブルロックへのエスカレーションがありません。一方MySQLはエンジンにより異なり、InnoDBは行ロックですがMyISAMではテーブルロックしか持たないため注意が必要です。
スケーラビリティ
大規模システムへの対応力にも差があります。Oracleは企業向け大規模環境を念頭に置き、Oracle Real Application Clusters (RAC) やシャーディング、In-Memory機能などにより高いスケーラビリティと可用性を実現します。一方、MySQLは中小規模システムやWebアプリでの水平スケーリングに強みがあります。MySQLはレプリケーションによるスケールアウトや、1サーバー内でのチューニングによる垂直スケールアップを柔軟に組み合わせられます。例えば読取負荷の高いシステムではマスタ・スレーブ構成でスレーブを増やすことで読み取り性能を向上できます。ただし、MySQLで複数ノードへの同時書き込みを行う場合はMySQL Cluster (NDB) やGroup Replicationといった特殊な構成が必要で、Oracle RACのような透過的なトランザクション共有とは異なるアプローチになります。
拡張性（機能拡張・プラグイン性）
Oracleは一つのエンジンに非常に多くの機能を内包しており、空間データ(SDO)、XML DB、マテリアライズド・ビュー、Javaストアドプロシージャなどエンタープライズ機能が豊富です ( [3] )。またPL/SQLによる強力なサーバーサイド処理や、ファインチューニング可能なメモリ管理、パラレルクエリなどで拡張性・柔軟性が高く、大規模基幹系での利用実績があります。一方、MySQLはプラガブルなストレージエンジン構造を持ち、InnoDB以外にもMyISAM・Memory・CSV・NDB Clusterなど用途に応じてストレージエンジンを差し替え可能です。例えば読み込み高速重視ならMyISAM、トランザクション必要ならInnoDBという使い分けができます（Oracleにはこのようなエンジン切替の概念はありません ( [4] )）。MySQLは軽量でシンプルなアーキテクチャのため導入や開発が容易ですが、その分機能面ではOracleに劣り、必要な機能はアプリケーション側で実装するケースもあります。
移行時の注意: トランザクションとスケーラビリティ
MySQLからOracleに移行する際は、暗黙のコミットの差異に注意しましょう。MySQLでは各DDL実行後に自動コミットされますが、OracleでもDDL/DCL実行時には暗黙コミットが発生します ( [1] )。またMySQLのオートコミットに慣れたアプリケーションでは、Oracle移行後にコミット漏れでロックが残留しないようトランザクションの境界管理を明確にする必要があります。スケーラビリティ面では、OracleではRACやData Guardで実装していた高可用性クラスタを、MySQLではレプリケーションによる冗長化やプロキシを用いたシャーディングで再設計する必要があり、整合性やフェイルオーバーの動作検証が重要です。特にOracle RACからMySQLへの移行では、マルチマスタ構成の要否やデータ一貫性モデルの違い（Oracleは強整合、MySQLレプリケーションはデフォルト非同期）に留意してください。
2. SQLの構文・データ型の違い
SQL文法と標準SQL互換性
OracleとMySQLではSQL標準に対する実装や拡張が異なります。Oracleは長年の独自拡張やチューニング機能があり、たとえば階層型SQL (CONNECT BY句) や 分析関数（OVER句）、MERGE文、DECODE関数などをサポートし、高度なクエリを単一SQLで実現できます。一方、MySQLは標準SQLに比較的素直ですが、歴史的にCTE（WITH句）や分析関数をサポートしていなかったため（MySQL 8.0で対応） (
[3]
)、Oracle特有のSQLを多用したアプリケーションを移行する際には書き換えが必要です。またLIMIT句による行数制限はMySQL独自（SQL標準はFETCH FIRST N ROWS句またはOracleのROWNUM）なので、Oracle移行時にはROWNUMフィルタや12c以降のFETCH/OFFSET句に置換する必要があります。構文上の大小文字やクオートの扱いも違いがあります。Oracleではデフォルトで識別子は大文字に正規化され、ダブルクオーテーションで囲むと大文字小文字が区別されます。MySQLではバッククオート (`) で識別子を囲み、小文字正規化（OS設定による）されるケースが多いです。この違いにより、テーブル名やカラム名の大文字小文字がコードにハードコーディングされていると移行後に参照エラーとなる可能性があります。
データ型の違い
MySQLとOracleではサポートするデータ型やその挙動にも差異があります。特にDATE/TIMESTAMP型と数値型（NUMBER/INTなど）の違いは移行時の注意点です。OracleのDATE型は日時を秒単位まで含む型であり、日付と時刻を一括して管理します。一方、MySQLではDATE型は日付のみ、DATETIME型やTIMESTAMP型で日時を扱います。Oracleで時刻の細粒度やタイムゾーン情報が必要な場合はTIMESTAMP型（TIMESTAMP WITH TIME ZONE等）を使いますが、MySQLのTIMESTAMP型はタイムゾーンを内部的にUTC変換して保持し、また自動更新の特性（DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMPなど）を持つ点で異なります。さらに、OracleではNULLと空文字列を同一視する仕様があり、VARCHAR2型に空文字’‘を挿入するとNULLとみなされます (
[1]
)。MySQLでは空文字は明確にNULLとは別物として扱われます。この相違で、データ移行後に空文字がすべてNULLになったり、その逆でNULLが空文字として扱われてしまうことで、アプリケーションのロジックに不具合が生じることがあります。
また、数値型ではOracleは可変精度のNUMBER型を使い、精度とスケールを指定できます。例としてOracleのNUMBER(10,0)は10桁の整数を表し、NUMBER単独指定では38桁までの可変長数値となります。一方、MySQLはINTやBIGINT, DECIMALなどサイズ固定もしくは精度固定の型が中心です。MySQLのBIGINTは64ビット整数ですが、Oracleで同等の整数を扱う場合NUMBER(19,0)などにマッピングされます (
[5]
)。小数を扱うDECIMALも、OracleではFLOATやNUMBERに変換されることがあります (
[5]
)。このように一部データ型は直接互換性がなく、たとえばMySQLのENUM型はOracleには存在しないため、文字列型＋チェック制約/トリガーで対応する必要があります (
[5]
)。文字列型では、OracleのVARCHAR2は最大4000バイト長ですが、MySQLのVARCHARは最大65535バイト（ただし行全体での制約あり）です。超長文はMySQLではTEXT/LONGTEXT型、OracleではCLOBで扱いますが、サイズ上限や関数サポートに差異があります。
移行時の注意: データ型とSQL文法
データ型変換では、自動変換ツール任せにせず重要な型の差異を洗い出すことが重要です。例えば、MySQLのDATETIMEやTIMESTAMPはOracleでは通常DATE型にマップされますが (
[5]
)、ミリ秒精度が必要ならOracleのTIMESTAMP型を使用する、といった判断が必要です。また、MySQLでTRUE/FALSE用途にTINYINT(1)を使っていた場合、OracleにはBOOLEAN型がないためNUMBER(1)やCHAR(1)に変換し、アプリ側で0/1をtrue/falseと解釈する対応が一般的です。SQL構文では、移行に際してクエリの書き換えが発生する代表例としてLIMIT句、日付関数、文字列関数の違いが挙げられます。MySQLのCONCAT_WSやIFNULLといった関数は、OracleではCONCATやNVLに置き換える必要があります。さらに、OracleはFULL OUTER JOINや階層問い合わせをサポートしますが、MySQLでは（バージョン8.0未満では）サポートが無かったため、外部結合のクエリを組み直したり、階層データ取得をアプリで再帰処理するなどの改修が必要でした (
[3]
)。移行時には、使用中のSQLで両製品間の非互換点を洗い出し、標準SQLで書き直すか、データベース特有の機能を代替手段に変更することが求められます。
3. ストアドプロシージャ・トリガーの違い
ストアドプロシージャ言語の違い
Oracleのストアドプロシージャ言語であるPL/SQLは、強力で洗練された手続き型言語です。PL/SQLは変数宣言、例外処理、カーソル、レコード型、配列型（コレクション）、そしてパッケージによるモジュール化など充実した機能を備えています。Oracleでは関連するプロシージャや関数をパッケージにまとめ、共通の変数や処理を共有できます。一方、MySQLのストアドルーチン（プロシージャ/関数）はSQL/PSM標準に近い構文ですが、機能面で限定的です。MySQLにはパッケージ概念が無く、ストアドプロシージャは個別に作成・管理します (
[3]
)。またPL/SQLに比べエラーハンドリング（ハンドラ）の柔軟性や最適化の高度さで劣ります。例えば、OracleではEXCEPTIONブロックで細かな例外処理が可能ですが、MySQLではハンドラで続行/終了の制御を行う程度です。また再帰的なSQLや複雑な演算はPL/SQLで効率的に実装できますが、MySQLでは一部サポートされない構文があり、必要ならアプリケーション側で処理することになります。Oracleのストアド関数はSQL文から呼び出せますが、MySQLのストアド関数も一応SELECT文で呼び出せるものの、特定の制限下でのみ使用が推奨されます。パフォーマンス面でも、OracleのPL/SQLは長年の改善で高速に動作し、大量データ処理に耐えうる一方、MySQLのストアドプロシージャは複雑な処理ではパフォーマンス上ボトルネックになる場合もあります（シンプルなトリガーやルーチン程度であれば問題ありません）。
トリガーの違い
トリガー機能にも両者で大きな差があります。Oracleはトリガー種別が豊富で、DMLトリガー（テーブルやビューに対するINSERT/UPDATE/DELETE）、DDLトリガー、ログオン・ログオフ時やエラー発生時などのデータベースイベントに対するトリガーを作成できます (
[6]
)。さらにOracleのDMLトリガーは1つのテーブルに対し複数のトリガーを同じイベント・タイミング（例えば BEFORE INSERT）でも作成可能で、11g以降ではFOLLOWS句で実行順序を制御することもできます (
[6]
)（順序指定しない場合、Oracleは同一タイミングの複数トリガーの実行順序を保証しません）。また行ごとのトリガー (FOR EACH ROW) だけでなく文単位のトリガーも定義でき、後者はSQL文が影響した行数に関わらず1回だけ実行されます (
[6]
)。例えば「DELETE文で100行削除してもトリガー処理は1度だけ行う」という制御が可能です。一方、MySQLのトリガーは機能が限定され、テーブルごとのDMLトリガーのみに対応します。イベントもINSERT/UPDATE/DELETEに限られ、ビューやDDL、ログオンといったイベントトリガーはサポートされません (
[6]
)。MySQLでは各テーブルにつき各タイミング（BEFORE/AFTER）・イベントごとに1つのトリガーしか持てません（同じテーブルにBEFORE INSERTトリガーを2つ作成することはできない） (
[6]
)。ただしMySQL 5.7.2+ 以降では同一イベントに複数トリガーを作成できるよう拡張され、作成順やPRECEDES/FOLLOWS句で実行順序も制御可能になりました (
[7]
)。加えて、MySQLのトリガーはすべて各行に対する行トリガーとして動作します (
[6]
)。Oracleのような文トリガーは無いので、例えば大量データを一括更新する際に集計処理等をトリガーでまとめて実行、といった場合でもMySQLでは行ごとにトリガーが発火しパフォーマンスに影響します。
移行時の注意: ストアドプロシージャ＆トリガー
OracleからMySQLへの移行では、PL/SQLで書かれたビジネスロジックをどう置き換えるかが最大の課題です。MySQLはPL/SQLが使えないため、ストアドプロシージャや関数は一からMySQLストアドルーチン文法で書き直す必要があります。特にパッケージはMySQLに無いため、パッケージ内のプロシージャ群は個別のルーチンとして整理しなおし、パッケージ変数で共有していた状態はテーブルやセッション変数で代替する必要があります。またPL/SQL固有の関数（例えばDBMS_%パッケージの利用など）があれば、同様の機能を持つMySQL関数やサードパーティツールで代替する検討が必要です。トリガーについては、Oracleで複数設定していたものはMySQLでは単一に統合するか、もしくはアプリケーション側で同様の処理を実装することが求められます。例えば複数の BEFORE UPDATE トリガーをOracleで使っていた場合、MySQLでは一つのトリガーにロジックをまとめる必要があります (
[6]
)。さらに、OracleのINSTEAD OFトリガー（ビューに対するトリガー）を使ってビューを更新可能にしていたケースは、MySQLではそもそもサポートが無いため、ビューを実表に置き換えるか、更新処理をアプリ側に実装する対応が必要です。逆にMySQLからOracleへの移行では、トリガー数やストアドの上限が緩和されるメリットもありますが、トリガーやストアドを安易に増やしすぎるとOracle側でメンテナンスが煩雑になるため、必要最小限にとどめるのが無難です。特にMySQLでトリガーが無かったCHECK制約代用ロジックなどは、Oracle移行後はCHECK制約を用いてシンプルに定義し直すといった改善も可能です (
[1]
)。いずれにせよ、ストアドやトリガー移行時には単純な文法変換だけでなく、処理方式の見直し（一部はアプリケーション層への移動も含め）を検討することが重要です。
4. インデックス・最適化の違い
インデックスの種類
Oracleは多彩なインデックスをサポートし、B木インデックスに加えてデータウェアハウス向きのビットマップインデックス、関数や式に対するファンクション索引、複合列やパーティションごとの索引など高度な機能があります。一方、MySQLの代表的ストレージエンジンInnoDBでは基本はB+treeインデックスのみで、索引の種類は限定的です（全文検索用のFULLTEXT索引やGIS用のR-tree索引が特殊用途で存在）。ビットマップ索引はMySQLには無いため、列の値の種類が少ない（低選択性）カラムを複数組み合わせて効率化するといったOracle特有の最適化はMySQLではできません ( [1] )。代替として、MySQL 8.0では仮想生成カラムに関数結果を保持して索引を貼ることでOracleのファンクション索引に近い効果を出すことは可能です。また、Oracleはインデックスを使用しないヒントを与えることで索引を一時的に無効化（インビジブルインデックス）したテストもできますが ( [8] )、MySQLにはそうした機能は限定的です（一般にDROP/CREATEで対応）。
クエリ最適化アプローチ
Oracleのクエリオプティマイザは高度に発達したコストベース最適化(CBO) で、統計情報を基に実行計画を作成します。ハッシュ結合・ソートマージ結合・ネストループ結合など様々な結合手法を駆使し、並列実行も自動判断します。DBAはヒント句（/*+ ヒント */）を使ってオプティマイザに介入でき、計画を固定するSQL計画管理機能もあります。一方、MySQLのオプティマイザもコストベースではありますが、Oracleほど多彩なアプローチは取りません。結合順序の最適化やインデックス選択は行いますが、基本的に単一テーブルにつき1つの索引利用が原則となります（OR条件の最適化で複数索引をマージする程度の例外はあります）。Oracleが複数索引を組み合わせてビットマップ変換するようなケースでも、MySQLは索引合致しない条件は全表スキャンとなることが多いです。またOracleはクエリ並列化が可能で、大規模照会をマルチCPUで分担できますが、MySQLは一つのクエリを単一スレッドで処理する（MySQL 8.0現在、一部並列クエリ機能は限定的）点も違いです。
統計情報の扱いにも差があります。OracleはANALYZEや自動統計収集により表・索引の統計量を管理し、古くなると最適化計画が悪化するため定期的な収集が必要です。MySQLもANALYZE TABLEで統計を更新しますが、InnoDBでは自動で適宜更新されるため管理負荷は比較的低めです。ただしMySQLでは統計が簡易で、複合条件時の行数推定が不正確なこともあり、必要に応じてヒント（例えばFORCE INDEXやSTRAIGHT_JOIN）でオプティマイザに指示を与えるチューニングも発生します。Oracleのヒントは非常に多数ありますが、MySQLはごく限られています（JOIN順固定のSTRAIGHT_JOINや索引利用強制のFORCE INDEXなど）。
移行時の注意: インデックスとクエリ性能
MySQLからOracleへ移行する場合、既存クエリの性能が索引構成の違いで変化することに注意します。例えばMySQLで部分的にインデックスが効いていたクエリが、Oracleではファンクション索引を作成することで大幅に効率化できる可能性があります。また、MySQLでは黙殺されていたCHECK制約違反データがOracle移行時に一括投入でエラーになる、といったケースもあり得ますので、データ整合性チェックを事前に行うことも重要です。反対にOracleからMySQLへの移行では、Oracleで使っていたビットマップ索引やパーティション分割が無くなることで一部クエリ性能が落ちるリスクがあります。特にデータ量が多いテーブルで低選択性カラムの組み合わせ検索をしているような場合、MySQLではインデックスを絞り込めず全表走査になりがちです。そのため必要に応じて複合インデックスを追加したり、アプリケーション側でクエリを見直す（条件を分けて処理するなど）対策を検討してください。また、Oracleのヒント句はMySQLでは使えないため、移行時にはヒント句を除去しMySQL流に最適化する必要があります (
[1]
)。MySQLはシンプルなクエリ構造を好むため、Oracleで有効だった複雑なサブクエリを含むSQLが遅くなる場合には、ビューの活用や一時テーブルへの分割などリファクタリングも効果があります。実行計画の確認方法も異なるため、Oracle移行後はEXPLAIN PLAN、MySQL移行後はEXPLAINでそれぞれプランを検証し、適切な索引・クエリ調整を行うことが成功のポイントです。
5. ライセンス・コスト面での違い
MySQLのライセンス形態
MySQLは基本的にオープンソース（GPLライセンス）で提供されており、誰でも無償で利用できます。Oracle社から提供されているMySQL Enterprise Editionもありますが、これは追加の監視ツールやバックアップツール、クラスタリングツールなど商用拡張を含んだサブスクリプションモデルです。コミュニティ版とエンタープライズ版でコアエンジン自体の性能差はありません。したがって、多くのケースでMySQLはライセンスコストゼロで導入・複製が可能であり、予算が限られたプロジェクトやOSSを好む企業で採用されています ( [1] )。一方で、公式サポートや追加機能が必要な場合には有償のEnterpriseサブスクリプション契約を結ぶことで手厚いサポートを受けられます。なお、MySQL派生のMariaDBやPercona Serverも同様にOSSであり、フォーク先独自のサポートプランが存在します。
Oracle Databaseのライセンス形態
Oracle Databaseは商用ソフトウェアであり、本番環境での利用には通常高額なライセンス費用が発生します ( [1] )。ライセンス形態はプロセッサライセンス（CPUのコア数に基づく課金）やNamed User Plus（想定ユーザ数に基づく課金）などがあり、エディションによって価格が異なります。エディションは主に無償のExpress Edition (XE)、機能限定・低価格のStandard Edition (SE/SE2)、フル機能のEnterprise Edition (EE)に分かれます。Express Editionは開発や小規模用途向けに提供され、例えば最新のOracle Database 21c XEではCPU使用は2コア、メモリ2GB、DBサイズ12GBまでなど制限があります。Standard EditionはRACが2ノードまでなど機能制限がありますが、中堅規模までの用途をカバーします。Enterprise Editionはオプション製品（Partitioning、Active Data Guard、Advanced Securityなど多数）を追加購入することで機能拡張も可能ですが、その分コストも非常に高額になります。「Oracleは高機能高性能のため圧倒的に高い」という声もある通り ( [1] )、総所有コスト(TCO)はMySQLに比べて大きく上回るケースがほとんどです。ただし、Oracle製品には充実したサポートと最新技術へのアクセス（例えばインメモリDBやマルチテナント機能等）が含まれるため、ミッションクリティカルなシステムでは費用対効果に見合う選択となります。なお、Oracle社はMySQLも保有していますが、MySQL自体はGPLのまま開発が続けられている点も付記しておきます。
移行時の注意: コスト評価
データベース移行では、ライセンスコストの変動も無視できません。MySQLからOracleへの移行では、これまで無料で使えていたデータベースに対し大幅なコスト増が発生するため、ハードウェア構成やコア数を踏まえたライセンス見積もりが必要です。場合によっては全てEnterprise Editionでなく一部機能はXEやStandard Editionで代替できないか検討することもあります（ただし機能差に注意）。逆にOracleからMySQLへの移行ではコスト削減が期待できますが、Enterprise版MySQLの有償ツールやサポートを利用するか、完全にコミュニティ版で運用するかを決める必要があります。コミュニティ版を使う場合、商用サポートが無いため社内に十分な知見を持つDB管理者を確保するか、信頼できるサポート企業と契約するなどリスクヘッジを検討してください。また、Oracleで使っていた機能がMySQLではOSSでは実現できずサードパーティ製品（これも有償）を導入することになれば、結果的にコストメリットが薄れることもあります。ライセンスだけでなく、移行に伴う再開発工数やチューニングコストも含めて総合的に判断することが重要です。
6. MySQL → Oracle 移行時の課題や陥りやすい罠
データ型の不一致
上述した通り、MySQLとOracleでは同名でも挙動が異なる型があります。例えばDATETIMEやTIMESTAMPはOracleのDATE型にマップされるため、タイムゾーンや閏秒の扱いなど微妙な差異に注意が必要です (
[5]
)。またMySQLでTEXTやLONGTEXTを使っていた場合、Oracleでは対応するCLOB型に変換しますが、文字コードやサイズ上限（OracleのCLOBはデフォルト4GB）に問題がないか検証します。ENUM型のようにOracleに存在しない型は、チェック制約付きVARCHAR2等に変換され (
[5]
)、関連するアプリケーションロジックも変更必須です。数値では、MySQLのAUTO_INCREMENT（主キーの自動採番）はOracleには無いため、シーケンス＋トリガーで同等機能を再現するか、Oracle 12c以降で導入されたIDENTITY列を使用します (
[9]
)。移行時にAUTO_INCREMENTをシーケンスに置き換えるのを忘れると、新規挿入で主キー重複エラーとなるので注意してください。
SQL構文の違いによる移行SQL修正
MySQLで使用していたSQL文がOracleではそのまま実行できないケースが多々あります。典型例として、一度のINSERT文で複数行を挿入する構文(INSERT ... VALUES (...), (...), ...)はMySQLでは有効ですが、Oracle 11gまではサポートされておらず、INSERT文を連打するかサブクエリを用いたINSERT ALL文に書き換える必要があります (
[9]
)。またLIMIT句やON DUPLICATE KEY UPDATE句、REPLACE INTO文などMySQL特有の構文は、OracleではそれぞれROWNUM＋ORDER句やMERGE文でのUPSERTに変更します。ストアドプロシージャも構文が異なるため自動変換は難しく、手動でPL/SQLに書き換える必要があります。特にカーソルループやエラー処理、関数の戻り値の扱いなど細部で違いが出るため、一つ一つ丁寧に対応します。さらに、MySQLではデータベース名.テーブル名で他データベースのテーブル参照ができましたが、Oracleではスキーマ（ユーザ）名.テーブル名となり、スキーマが異なる場合は権限付与やシノニム作成が必要です。このスキーマとデータベース概念の違いも移行時につまづきやすいポイントです (
[9]
)（MySQLでいう「データベース」はOracleでは「スキーマ（ユーザ）」に相当します）。複数のMySQLデータベースを一つのOracleインスタンスに移行する際は、Oracle上でスキーマを分けて作成し、それぞれにオブジェクトをインポートする形になります。
トランザクション管理の差異
Oracleは前述のように自動コミットされないため、MySQLで明示的にコミットしていなかったアプリケーションはOracle移行後にコミット漏れが起きやすくなります。特にバッチ処理など長時間トランザクションを開くと、OracleではUNDO保持やロックの観点から問題になる場合があります。また、MySQLではREAD UNCOMMITTEDなどの分離レベルも設定可能でしたが、OracleはREAD COMMITTEDかSERIALIZABLEのみです。MySQLのトランザクション分離レベルを変更してチューニングしていた場合、その設定はOracleには直接対応するものが無いので注意が必要です。もう一つ、OracleではSELECT文も暗黙的にトランザクションを開始します (
[1]
)。そのため、何も更新していなくても明示的にROLLBACKしない限りセッションが保持され、後続DDLがブロックされることがあります。MySQL中心のエンジニアはここで戸惑うことが多いため、「Oracleでは明示的な終了処理（コミット/ロールバック）が必要」という教育を徹底しましょう。
パフォーマンスチューニングの違い
MySQLで問題なく動いていたクエリが、Oracleに移行した途端に遅くなるケースもあります。原因の一つは、オプティマイザの違いによる実行計画の相違です。MySQLではインデックスを使っていたがOracleでは別のアクセス経路を選択する、といった場合、統計情報を適切に収集した上でヒント句の付与や索引の追加作業が必要になります (
[1]
)。特に、文字列のソートやLIKE検索ではOracleとMySQLで最適化方法が異なるため、場合によってはOracle用にヒント句（FULL()やINDEX()など）で微調整したり、アプリ側で検索方法を見直すことが必要です。またハードウェア構成も見直しポイントです。MySQLはスケールアウト前提で比較的低スペックなサーバを並べる構成が多いですが、Oracleは高性能サーバでスケールアップする構成が一般的です。そのため移行の際にインフラ構成を変更した結果、ネットワーク帯域やストレージIOPSなどボトルネック箇所が変わる可能性もあります。実例として、ある中規模システムでMySQLからOracleへ移行した際、夜間バッチ処理が極端に遅延する問題が発生しました。調査すると、MySQLではスキーマを分けていた処理をOracleでは同一ユーザに統合した結果、不必要なテーブル結合が行われていたことが判明しました。最終的に結合条件を見直し索引を追加することでOracle上でも性能を確保できた、というケースがあります。このように、移行後のチューニングでは単純なパラメータ変更だけでなくクエリリファクタリングも視野に入れて対応する必要があります。
その他の罠
大文字小文字を区別しない照合順序や、文字コード（MySQLのUTF8は実質3バイトまでだがOracleのAL32UTF8は4バイトUTF8対応）など、細かな点での挙動差にも注意しましょう。特に絵文字など4バイト文字を扱っていた場合、MySQLからOracleへは問題ありませんが、逆方向では文字化けする可能性があります。また、Oracleは予約語や識別子の長さ制限（以前は30文字まで、12c以降は128文字まで）に制約があるため、MySQLで長いテーブル名・カラム名を使っていた場合はリネームが必要になることもあります。移行時にはこれら「見落としがちな違い」のチェックリストを作成し、一つ一つ対処することが成功の鍵です。
7. Oracle → MySQL への移行時の課題や罠
PL/SQLが使えないことによる影響
Oracleで大量のビジネスロジックをPL/SQLのストアドプロシージャや関数、パッケージで実装していた場合、そのままではMySQLに移植できません。MySQLのストアドプロシージャ言語は機能が限定され、Oracleのようなパッケージによるモジュール化や高度な例外処理ができません ( [3] )。このため、可能であればロジック自体をアプリケーション層（JavaやPythonなど）に移して保守しやすくすることが検討されます。移行プロジェクトでは、DB内で完結していた処理を取り出す作業が大規模になるケースが多く、スケジュールに余裕を持つべきです。どうしてもMySQL側でストアドを再実装する場合、パフォーマンス面でもOracleほど効率が出ない恐れがあるため、重要な処理は事前にベンチマークを行いボトルネックがないか検証してください。トリガーについても、Oracle特有の複雑なトリガーロジック（例: 複数テーブルにまたがる監査トリガーやDDLトリガーでの監視など）はMySQLでは実現困難です。代替として、アプリケーションで対応するか、監査用にMySQLのbinlogを解析するツールを導入するなどの対策が必要になります。
標準SQL機能差によるクエリの変更
Oracleで使用していたクエリの中には、MySQLで書き換えが必要なものが多くあります。例えば階層問い合わせ（CONNECT BY句）を使ったSQLは、MySQL 8.0以降であれば再帰的CTE（WITH RECURSIVE）で書き換えることが可能ですが (
[3]
)、それ以前のMySQLでは対応不可のためアプリ側でツリー走査処理を実装する必要があります。また分析関数（ROW_NUMBER()やRANK()などウィンドウ関数）はMySQL 8.0でこそサポートされましたが、それ以前は同等機能がなかったため、統計集計処理などをSQLだけで行っていた場合はロジックを変更する必要があります。OracleのMERGE文（条件に応じINSERT/UPDATE）も、MySQLではINSERT ... ON DUPLICATE KEY UPDATEで近い動作をしますが細部が異なります。加えて、Oracle固有のSQL関数（DECODEやNVL2、CONNECT_BY_ROOT等）も、MySQLで類似の機能が提供されているか確認し、なければロジックを再構築します。シノニムやデータベースリンクもOracleにはありましたがMySQLには無いため、他スキーマ・他DB参照はアプリケーション側で別接続を持つなど実装変更が必要です。移行時には、SQLの互換性テストを十分に行い、結果がOracleと一致することを確認する作業に工数を割り当てましょう。
インデックス・最適化手法の違い
Oracleでチューニングのために作成していた索引や利用していたヒント句がMySQLでは活かせない場合があります。例えば、Oracleで作成していたビットマップ索引や機能索引はMySQLに移行後は消滅するため、クエリのWHERE条件に応じて複合インデックスや生成列を追加し直す必要があります。また、Oracleではテーブルをパーティション分割して特定範囲の問い合わせを高速化していたものも、MySQLでもパーティション機能自体はありますが実装が異なり制約も多いです（MySQLではパーティションキーが主キーに含まれていないといけない等の制限があります）。そのため、下手にパーティション移行するとINSERT/UPDATEが遅くなるなど弊害が出ることもあります。クエリの実行計画もOracleとMySQLで大きく変わる可能性があるため、移行後は一からチューニングが必要と考えてください。特に大量データを扱うOLAP的な処理では、Oracleは並列クエリや大量バッファキャッシュで高速化していたものが、MySQLでは一件ずつ処理になり遅くなるケースもあります。この場合、バッチ処理に分割したり、集計専用に別途データマートを設けることも検討します。
高可用性・スケーリングの考え方の違い
OracleからMySQLへ移行すると、システム全体の可用性アーキテクチャも見直す必要があります。OracleではRACによるアクティブ-アクティブクラスタやData Guardによるスタンバイ構成で強整合かつ自動フェイルオーバーを実現できますが、MySQLでは主に非同期レプリケーションによるマスタ-スレーブ構成が用いられ、即時フェイルオーバー時に数秒〜数分のラグやトランザクション損失リスクが伴います。MySQLでもGroup ReplicationやGalera Clusterでマルチマスタ構成を組めますが、Oracle RACほど透過的ではなくアプリ側での競合制御が必要になる場合があります。また、Oracleで実現していたフラッシュバッククエリ（過去の時点に戻ってデータを参照）やRedoログを使ったポイントインタイムリカバリなど高度な機能はMySQLでは標準で持ち合わせていません。バックアップ/リカバリ戦略もOracle流（RMANなど）からMySQL流（mysqldumpやxtrabackup、binlog活用）に変更する必要があります。これら可用性・災害復旧設計をOracle依存で組んでいた場合、MySQL移行後に同等の信頼性を得るには追加のツール導入やクラウドサービス活用など周辺対策を講じることが多いです。事例として、ある企業でOracle RAC + Data GuardでRPO=0/RTO≒0を実現していたシステムをMySQLに移行した際、代替手段としてMySQL Group Replicationと手動フェイルオーバースクリプトを組み合わせました。しかし完全同期ではなかったため、ネットワーク分断時にデータ不整合が発生するリスクを抱えることになりました。このように、OracleからMySQLへ移行する際は機能差による可用性要件の見直しが必要で、場合によっては要件緩和か、別途商用クラスタソリューションの導入検討も必要です。
以上、MySQLとOracleの違いを7つの観点で詳しく比較しました。それぞれの項目で機能や構文の差異を理解し、移行時の留意点を押さえることで、移行プロジェクトを計画・実施する際のリスクを軽減できます。実践的には、小規模なテスト移行を行い差異による問題点を洗い出すこと、互換性のチェックリストを作成すること、必要に応じて専門家の支援を仰ぐことが成功のポイントとなります。各種ツール（Oracle SQL Developerの移行機能やサードパーティの変換ツールなど）も活用しつつ、上記のような「ハマりやすい罠」を事前につぶして円滑な移行を目指してください。
参考資料
- 主なRDB（Oracle, MySQL, PostgreSQL）の機能比較 #oracle - Qiita
- Oracle Transaction Model and MySQL Transactions - Oracle to Aurora MySQL Migration Playbook
- How is mysql different from oracle performance-wise? - Stack Overflow
- How do you choose storage engines for Oracle? - Stack Overflow
- Oracle and MySQL Compared
- Triggers and Stored Procedures
- MySQL 8.4 Reference Manual :: 27.3.1 Trigger Syntax and Examples
- Oracle and MySQL invisible indexes - AWS Documentation
- Coming from MySQL, Going to Oracle: the Pitfalls - Stack Overflow
