MySQL 5.6での機能強化点(その1) - パフォーマンスと使い勝手を大きく向上

2013年11月19日(火)
山﨑 由章

MySQL 5.6:今までで最高のリリース

2013年2月にMySQL 5.6がリリースされました。このバージョンは、パフォーマンスや使い勝手も大幅に向上し、「今までで最高のリリース」と言われています。また、製品品質の面でも、従来のバージョンよりも高い評価を頂けています。その背景にあるのが、DMR(Development Milestone Release)という開発モデルです。

MySQLは現在、正式リリース前に年に2~4回程度新たな機能を追加した開発途上版をリリースし、ユーザーからのフィードバックを受けて品質を高めた上で、正式版であるGA(Generally Availability)をリリースする、という開発モデルを採用しています。例えば、MySQL 5.6の場合は、以下の図のようにDMRをリリースし、機能追加/品質向上を続けてきました(最後のRCは、Release Candidateを意味します。RCではGAに含まれる機能セットはほぼ確定した状態で、その後バグが修正されてGAがリリースされる、という流れになっています)。

図1:MySQL 5.6のリリース履歴(クリックで拡大)

そしてこのMySQL 5.6は、特に以下の点について機能強化しています。

  • InnoDB
  • オプティマイザ
  • パフォーマンススキーマ
  • レプリケーション
  • NoSQLオプション(Memcached API)

今回はこの中でも、InnoDBとオプティマイザの改善について解説します。

InnoDB:最も使用されているストレージエンジン

MySQLにはプラガブルストレージエンジンという機能があり、データを格納するストレージ部分を、用途に応じて柔軟に変更することができます。ストレージエンジンが変われば、データの格納方式やインデックスの実装方法が変わるだけでなく、同時実行制御の方式やトランザクションの有無も変わってきます。

MySQLはデフォルトの状態でも複数のストレージエンジンが使用できる状態になっていますが、その中でも、現在最も使用されているストレージエンジンはInnoDBというストレージエンジンです。
InnoDBは、トランザクションに対応したストレージエンジンで、MySQL 5.5以降のデフォルトストレージエンジンです。MySQL 5.5の時点でも、InnoDBの性能は大幅に向上していたのですが、MySQL 5.6では更に性能が向上しています。また、運用する上で便利な機能も多く追加され、使い勝手も大きく向上しています。

InnoDBの性能を更に向上

MySQL 5.6では、カーネルmutexの分割やバッファプールのフラッシュの効率改善など、内部の実装を改良することで、InnoDBの性能が更に向上しています。また、参照専用トランザクションや可変ページサイズなど、パフォーマンス改善につながる各種の新機能が実装されていますので、どのような機能か紹介していきます。

参照専用トランザクション

参照中心のアプリケーションの場合、参照専用トランザクションを使用することで、オーバーヘッドの削減が可能になりました。MySQL 5.6では、START TRANSACTION READ ONLYというシンタックスが追加されています。参照しか行わないトランザクションの初めにこのコマンドを実行することで、そのトランザクションは参照専用トランザクションと認識されます。そうすることで、更新処理に伴う内部的な準備が不用になる分、オーバーヘッドの削減ができ、パフォーマンス向上が期待できます。

ログファイルサイズの上限が増加

これまで、InnoDBのログファイルの上限は合計4GBまででしたが、メモリを大量に搭載しているサーバーで更新処理が多発する場合など、サイズが不十分になるケースもありました。そこで、MySQL 5.6ではログファイルの最大サイズを拡張し、最大512GBまでのログファイルを作成できるようになっています。

また、こちらはMySQL 5.5時点での改善点ですが、InnoDBのクラッシュリカバリ処理が高速化されています。これにより、サイズの大きいログファイルを問題なく活用できます。

可変ページサイズ

従来はInnoDBのページサイズは16KBに固定されていました。InnoDBはページ単位でI/Oするため、ページサイズはパフォーマンスに影響を与える要因の1つとなっています。例えば、大量の行を一度に更新するようなUPDATE処理では、ページサイズが大きい方が多くの行にまとめてアクセスすることができるためI/O効率が良くなりますが、1行だけを更新するUPDATE処理では、ページサイズが小さい方が余分なデータが少なくなるためアクセス効率が良くなります。また、I/Oの特性はハードウェアによっても異なります。

HDDはランダムアクセスが苦手ですが、SSDはランダムアクセスが得意です。16KBというページのサイズは、ランダムアクセスが苦手なHDDを考慮し、1回のアクセスである程度まとまったサイズのデータをやり取りできるように設定されていました。しかし、ランダムアクセスが得意なSSDの環境では、ページサイズが小さい方が全体のスループットが向上する可能性もあります。そこで、MySQL 5.6ではページサイズをパラメータで変更できるようにしました。

ページサイズを変える場合は、インスタンス作成時に以下のパラメータを設定しておきます。

-	innodb_page_size=4k

※設定可能な値は4k、8k、16k(デフォルト値は16k)詳細はこちらを参照下さい。

インスタンス作成後、後からページサイズを変更することや、テーブル単位でページサイズを変更することはできないので、注意して下さい。

SSD環境に向けた最適化

InnoDBには、バッファプール上で変更されたデータをディスクに書き出す場合に、近隣のページをまとめて1回のI/Oで書き出す仕組みがありますが、この仕組みはランダムアクセスが苦手なHDD向けに最適化された機能です。
SSDの環境では、必要なページのみをディスクに書き出した方が全体の処理効率が上がるため、近隣ページの書き出しを無効化できます。近隣ページの書き出しを無効化する場合は、以下のパラメータを設定します。

-	innodb_flush_neighbors=0

※設定可能な値は0、1、2(デフォルト値は1)詳細はこちらを参照下さい。

UNDO表領域の分離

UNDOログ(ロールバックセグメント)専用の独立したテーブルスペースを作成できるようになりました。ディスクが複数ありI/O分散できるケースなどでは、別ディスクにUNDO表領域を配置することで、パフォーマンス向上が期待できます。

日本オラクル株式会社

MySQLのセールスコンサルタント。元々はOracleデータベースのコンサルティング、サポート等に従事していたが、オープンソースとフリーソフトウェア(自由なソフトウェア)の世界に興味を持ち、MySQLの仕事を始める。趣味は旅行と美味しいものを食べること。

連載バックナンバー

Think ITメルマガ会員登録受付中

Think ITでは、技術情報が詰まったメールマガジン「Think IT Weekly」の配信サービスを提供しています。メルマガ会員登録を済ませれば、メルマガだけでなく、さまざまな限定特典を入手できるようになります。

Think ITメルマガ会員のサービス内容を見る

他にもこの記事が読まれています