連載
OracleからMySQLへ 「SQL」と「DDL」の移行評価を実施する：実践 OSSデータベース移行プロジェクト（5）（2/3 ページ）
本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は、Oracle DatabaseからMySQLへの移行に向けた「SQL」と「DDL」の移行評価ポイントを解説します。
手順3：「移行評価」を行う
SQLの移行評価
現行ビュー、ストアドプロシージャ、DMLトリガに実装しているSQL（SELECT文）をMySQLに移行する場合に「難易度が高くなる要素を含む3事項」についての評価を行います。
- （1）「外部結合の構文の移行」に関する評価結果
Oracleの外部結合の構文には、「Oracle方言」と「ISO標準」があります。
| 外部結合構文 | 構文例（コメント） | 本システムでの個数 | 移行コスト評価 |
|---|---|---|---|
| Oracle方言（WHERE句における外部結合条件のデータが不足している側に結合演算子（＋）を定義する） | Oracle構文例： SELECT e.ename,d.dname,d.loc,d.deptno FROM emp e, dept d WHERE d.deptno = e.deptno (+); |
259 | ISO標準の記載方法に変換する必要があるため、修正箇所が多い。移行コストは「高」 |
| MySQL構文例： （記述不能） |
─ | ||
| ISO標準（ISO準拠構文でOracle 9iから採用。RIGHT/LEFT OUTER JOINにより、OUTER JOINの左右どちらかから結合条件が不足している行も取り出す） | Oracle構文例： SELECT e.ename,d.dname,d.d,loc,d.deptno FROM emp AS e RIGHT OUTTER JOIN dept AS d ON d.deptno = e.deptno; |
0 | 変更必要はない。移行コストは「低」 |
| MySQL構文例： （Oracle構文と同一） |
─ |
- （2）SQL関数移行に関する評価
OracleのSQL関数は、移行の観点で分類すると大まかに5つに分類できます。
| Oracle SQL関数の種別 | 構文例（コメント） | 本システムでの個数 | 移行コスト評価 |
|---|---|---|---|
| 関数名、パラメータ指定ともに変更せずMySQLで使えるSQL関数 | Oracle構文例： ・SELECT ASCII('a') FROM dual; ・SELECT CONCAT('a','b') FROM dual; |
118 | ソースコードの変更は必要ない。移行コストは「低」 |
| MySQL構文例： （Oracle構文と同一） |
─ | ||
| 関数名は変更なし、パラメータ指定を変更すればMySQLで使えるSQL関数 | Oracle構文例： ・SELECT INSTR('漢字の検索の結果','の',1,2) FROM dual; ・SELECT SYSDATE FROM dual; |
145 | ここで使用しているSQL関数は、パラメータの記載部分を書き換えるだけで同一の結果が得られる。移行コストは「中程度」 |
| MySQL構文例： （MySQLにてパラメータが不足している場合は、別途ユーザー定義関数の作成が必要） ・SELECT INSTR('漢字の検索の結果','の') FROM dual; ・SELECT SYSDATE() FROM dual; |
─ | ||
| パラメータ指定変更なし、関数名を変更すればMySQLで使えるSQL関数 | Oracle構文例： ・SELECT CHR(97) FROM dual; ・SELECT LENGTH('漢字の長さ（文字数）') FROM dual; ・SELECT LENGTHB('漢字の長さ（BYTE）') FROM dual; |
92 | ソースコードの変更は少ないが、数が多い。移行コストは「中程度」 |
| MySQL構文例： ・SELECT CHAR(97) FROM dual; ・SELECT CHARACTER_LENGTH('漢字の長さ（文字数）') FROM dual; ・SELECT LENGTH('漢字の長さ（BYTE）') FROM dual; |
─ | ||
| 関数名、パラメータ指定ともに変更すればMySQLで使えるSQL関数 | Oracle構文例： ・SELECT USERENV('sessionid') FROM dual; ・SELECT TO_CHAR(12345) FROM dual; |
2511 | ソースコードの変更は少ないが、数が多い。移行コストは「中程度」 |
| MySQL構文例： ・SELECT CONNECTION_ID() FROM dual; ・SELECT CAST(12345 AS CHAR) FROM dual; |
─ | ||
| Oracle独自のSQL関数 | Oracle構文例： ・SELECT TO_MULTI_BYTE('A') FROM dual; （※シングルバイト文字を、対応するマルチバイト文字に変換） ・SELECT DUMP('abc', 1016) FROM dual; （※データ型コード、長さ(バイト単位)および内部表現を含むVARCHAR2値を戻す） |
2 | ストアドプロシージャにDUMP関数を2カ所使用しているために、DUMP関数のユーザー定義関数の作成が必要。移行コストは「高」 |
| MySQL構文例： （ユーザー定義関数作成が必要） |
─ |
- （3）ヒント句SQL移行に関する評価
Oracleのヒント句は、移行の観点で分類すると大まかに5つに分類できます。
| Oracle ヒント句の種別 | 構文例（コメント） | 本システムでの個数 | 移行コスト評価 |
|---|---|---|---|
| ヒント句を削除することによって、MySQLで使えるヒント句 | Oracle構文例： SELECT /*+ RULE */ ・・ （ルールベースのオプティマイザを選択） |
19 | SQLの変更は比較的容易で変更数は少ないが、別途チューニングにコストがかかる。移行コストは「中程度」 |
| MySQL構文例： （MySQLには、ルールベースとコストベースの選択がないために、「/*+ RULE */」を削除してSQL個別でチューニングする必要がある） |
─ | ||
| ヒント句をMySQLのSQL構文に変更することで、MySQLで同等のオプティマイザ挙動が得られるヒント句（※MySQLのUSE INDEX句に移行して使用できるヒント句） | Oracle構文例： SELECT /*+ INDEX(indexname)> */ ・・ （指定されたテーブルに対して、インデックス走査を選択） |
34 | SQLの変更は比較的容易で変更数は少ない。移行コストは「低」 |
| MySQL構文例： （MySQLにてパラメータが不足している場合は、別途ユーザー定義関数の作成が必要） SELECT ・・FROM tablename USE INDEX(indexname) ・・ （MySQLのインデックスに関するヒント句には、別途「FORCE INDEX」（正し、フルスキャンが非常に重いことを知らせた上で、指定したインデックスを使用することが推奨される）や「IGNORE INDEX」（使用しないインデックスを指定）がある |
─ | ||
| ヒント句をMySQLのSQL構文に変更することにより、MySQLで同等のオプティマイザ挙動が得られるヒント句（※MySQLのSTRAIGHT_JOIN句に移行して使用できるヒント句） | Oracle構文例： SELECT /*+ ORDERED */ ・・ （FROM句に現れる順序で表を結合するようOracleに指示する） |
22 | ヒント句を含むSQL変更はやや困難。特に外部結合構文にOracle方言が使用されているため、修正箇所が多くなる。移行コストは「高」 |
| MySQL構文例： SELECT ・・・ FROM XXXXX STRAIGHT_JOIN tablename ON ・・・・ （左側のテーブルが常に右側のテーブルの前に読み取られる点を除き、JOINと同じ。これは結合オプティマイザがテーブルを間違った順序で配置する数が少ない場合に使用できる） |
─ | ||
| ヒント句名および構文を変更することにより、MySQLで同等のオプティマイザ挙動が得られるヒント句（※MySQLのオプティマイザヒント句に移行して使用できるヒント句で、MySQL5.7.7から追加） | Oracle構文例： SELECT .. FROM tablename1 WHERE colname IN (SELECT /*+ NO_SEMIJOIN */ colname FROM tablename2); （SEMIJOIN＜副問い合わせを効果的にする処理するジョイン＞の最適化を実施しない） |
3 | ヒント句を含むSQL変更は比較的容易。移行コストは「低」 |
| MySQL構文例： SELECT .. FROM tablename1 WHERE colname IN (SELECT /*+ NO_SEMIJOIN */ colname FROM tablename2); （SEMIJOINの最適化を実施しない） |
─ | ||
| Oracle独自ヒント句のため、MySQLで使用できないヒント句 | Oracle構文例： SELECT /*+ ALL_ROWS */ （最高のスループットを目標として、文ブロックを最適化） |
2 | ヒント句を削除することは容易だが、別途実行計画を調整する必要がある。移行コストは「高」 |
| MySQL構文例： （ヒント句を移行できないので、別途実行計画を調整する必要がある） |
─ |
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
「Oracle Databaseをやめる」という選択肢
Oracle Databaseのライセンス体系が変更され、これまでSE1／SEを利用していたユーザーは「実質の値上げを受け入れる」か「Oracle Databaseをやめる」かの選択が迫られています。本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。初回は、本連載を展開する背景を説明します。
MySQLの「気になるウワサ」はどこまで本当？
Webの世界で人気の高いオープンソースRDB「MySQL」は、振り返ると買収や分岐など、運命に翻弄されてきましたが、中には正しくない話も出回っているようです。あの話は、本当ですか？
MySQL＋Apache＋PHPをインストールしよう
本連載は、これからWebアプリケーション開発を習得しようとする方や本格的なプログラミング経験の少ない方を対象にしています。連載途中から始まるサンプルWebアプリケーション（簡単なショッピングサイト）開発を進めていきながら、基本事項や注意点などについて詳しく解説していきます。
OSSデータベースのMySQLとPostgreSQLは「次の段階」へ進む
オープンソースデータベースの両雄、MySQLとPostgreSQLはどちらも近々大きく変化を遂げそうです。まだ公式発表前ですが、現在入手できる情報から「来たるべき進化」を考えます。
いよいよMySQL編、ソースからビルドすべきか？
今回から、オープンソースのRDBMSである「MySQL」の環境構築に話題を移します。まずはソースコードを探して入手と行きたいところですが、MySQLの場合はソースコードからのビルドが最善の策かどうかを考える必要があります（編集部）