OracleからMySQLへ 「SQL」と「DDL」の移行評価を実施する：実践 OSSデータベース移行プロジェクト（5）（2/3 ページ）

[荻野邦裕，SCSK株式会社]

手順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構文例： （ヒント句を移行できないので、別途実行計画を調整する必要がある）	─