Oracle DatabaseとMySQLは「何」が違うのか 「アーキテクチャの違い」を理解する：実践 OSSデータベース移行プロジェクト（2）（3/3 ページ）

本連載では、商用DBMSからOSSデータベースへの移行を検討する企業に向け、「MySQL」への移行プロジェクトで必要となる具体的なノウハウをお届けします。今回は「Oracle DatabaseとMySQLのアーキテクチャの違い」を解説するとともに、正しい設定／移行計画に向けたポイントを紹介します。

[廣濱顕司, 荻野邦裕, 潮雅人，SCSK株式会社]

【6】「ロック／トランザクション分離レベルの違い」を理解して、正しく設定する

　Oracle Databaseで選択できるトランザクション分離レベルは「READ-COMMITTED」か「SERIALIZABLE」ですが、MySQLではこれらに加えて、「REPEATABLE-READ」と「READ-UNCOMMITTED」を選択できます。デフォルト設定はREPEATABLE-READです。

　MySQLにおけるトランザクション分離レベルは、デフォルトのREPEATABLE-READではなく、「READ-COMMITTED」にすることを勧めます。理由は後述します。トランザクション分離レベルは、transaction-isolation（パラメータ名はtx_isolation）を指定することで設定できます。

　Oracle Databaseでのロックは、基本的には「行レベルロック」です。これはMySQLでも同様です。デフォルトでMySQLが使用するストレージエンジンである「InnoDB」を使用していれば、行レベルロックを取得します。ただし、MySQLのデフォルトトランザクション分離レベルであるREPEATABLE-READは、「ネクストキーロック」と呼ばれる仕組みによって、思わぬパフォーマンス劣化を招く可能性があるのです。

　ネクストキーロックとは、テーブルにある値のうち、明示的にロックを取得しようとした範囲の次の値までの範囲のロックを取得する挙動のことです。この挙動は、トランザクション分離レベルを「READ-COMMITTED」に設定することで回避ができます。

ポイント

• MySQLにはトランザクション分離レベルが4段階ある（「SERIALIZABLE」「REPEATABLE-READ」「READ-COMMITTED」「READ-UNCOMMITTED」）
• デフォルト設定REPEATABLE-READだが、「READ-COMMITTED」に修正することを推奨する
• その理由は、「ネクストキーロック」によってパフォーマンス劣化を招く可能性があるため
• ネクストキーロックは、「READ-COMMITTED」への設定変更で回避できる

【7】「オプティマイザの違い」を理解して、正しく設定する

　Oracle Databaseでは、オプティマイザを「ルールベース」と「コストベース」の2通りから選択できます。デフォルトはコストベースです。一方、MySQLのオプティマイザは「コストベースのみ」です。しかしOracle Databaseにおいても、ルールベースのオプティマイザを利用しているケースはさほど多くはないと思います。

　なお、MySQLはバージョン5.7で「JOIN時の対象行の見積もりの改善」など、大幅なオプティマイザのリファクタリングが行われました。このため、これから移行を検討するならば、MySQL 5.7以上のバージョンにすることをお勧めします。また、いざ実行計画を確認する場合には、「MySQL Workbench（*2）」の機能の1つである、「ビジュアルEXPLAIN」が直感的で便利です。もちろん一般的なEXPLAIN句による実行計画の確認もできますが、もしMySQL Workbenchを利用できる環境であれば、利用を検討してみてください。

*2：MySQLの統合ビジュアルツール。開発設計やサーバ設定、ユーザー管理などをGUIで行える。Community版も提供されている

　MySQLへ移行してから想定していたよりもパフォーマンスが出なかった場合は、オプティマイザの挙動変化が原因である可能性が考えられます。性能上の問題が発生した際には、SQLのチューニングを行うことが性能改善につながるケースが多いです。MySQLにおけるSQL改善には、以下のようなアプローチがあります。

MySQLにおけるSQL改善のアプローチ

1. スロークエリログなどから、問題になっているクエリを特定
2. EXPLAINで実行計画を確認し、想定通りのインデックスを使用しているかどうかを確認
3. インデックスの追加、クエリに対してHINT句でチューニングする

　もっとも、移行後の性能テストの段階でパフォーマンス問題が発覚すると、プロジェクトの遅延につながる危険性が大です。性能問題の可能性については、やはり前もってじっくりと検証しておくことが望ましいでしょう。

ポイント

• MySQLのオプティマイザは「コストベース」のみ
• MySQL 5.7で大幅なオプティマイザのリファクタリングが行われたため、「MySQL 5.7」以降を推奨する
• 実行計画を確認するには、MySQL Workbenchにある「ビジュアルEXPLAIN」を使うと便利

　次回は、Oracle DatabaseからMySQLへ「オブジェクトの移行」を行う際のポイントを解説します。

※本稿は、2016年9月20日 SCSK「Oracle DBからMySQLへ、DB移行プロジェクトの実践ノウハウを専門家が徹底解説」ホワイトペーパーより、提供者の許可の下、一部を修正して展開するものです。

筆者紹介

廣濱顕司（ひろはま けんじ）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。東京都出身　東京都在住。MySQLやMySQL Clusterのコンサルティング、設計構築、プリセールスなどを行っていたが、最近は営業やマーケティング活動もカバーするようになり、技術が分かる営業として日本国内を縦断中。

荻野邦裕（おぎの くにひろ）

SCSK株式会社所属。神奈川県横浜市在住。1983年よりIT業界へ。その間Oracleを中心とした、DB関連作業を多数経験。DBの移行を得意とする。趣味は自己チューニング（水泳、マラソン、筋トレ）及び愛犬アポロ（チワワ）と遊ぶこと。

潮雅人（うしお まさと）

SCSK株式会社 ITマネジメント事業部門 基盤インテグレーション事業本部 通信基盤インテグレーション部所属。神奈川県川崎市在住。入社当初よりデータベースの設計構築や技術サポート業務に従事。MySQLを中心にしつつもOracle Database、Oracle RACなどの構築にも携わる。趣味はスノーボード、スキューバダイビング、海外旅行など。