オラクル社のパートナー　ハートコア社MySQL（マイエスキューエル）

InnoDBの性能向上・機能追加

MySQL5.5で、MyISAMに代わって標準ストレージエンジンとなったInnoDBの性能が更に向上され、便利な新機能も追加されました。

トランザクション

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

オンラインDDL

DDLの実行やスキーマ変更が、オンラインで実行できるようになり、メンテナンス等の停止時間削減が実現されました。（CREATE/DROP INDEX、AUTO_INCREMENT値の変更、ADD/DROP FOREIGN KEY、RENAME COLUMN、テーブルのROW FORMAT/KEY_BLOCK_SIZEの変更、列のNULL/NOT_NULLの変更、列の追加・削除・並び替え）

ログファイルサイズ

ログファイルの最大サイズが拡張され、最大512GBまでのログファイルを作成できるようになりました。クラッシュリカバリ処理も既に高速化されているため、サイズの大きいログファイルも問題なく使用可能です。

各マスターは、固有のインスタンスによってスレーブサーバー内で処理されます。それぞれのインスタンスは、異なるI/Oスレッドと、SQLスレッド、および関連設定から構成されます。CHANGE MASTERを使って、インスタンスを指定します。

ページサイズ

"innodb_page_size"というパラメータが追加され、従来16KBで固定であったページサイズを、インスタンス作成時に変更できるようになりました。ページサイズが小さい方が全体のスループット向上が見込まれる環境では、パフォーマンス改善が期待できます。

ディスク書き出し

"innodb_flush_neighbors"というパラメータが追加され、近隣ページの書き出しを無効化できるようになりました。SSD環境では、これを無効化することにより処理効率の向上につながります。

データ移行

InnoDBのデータを、テーブル単位で別のMySQLサーバーへ移行できるようになりました。同一サーバー内でのバックアップ目的でも使用できます。

バッファプール

バッファプールにキャッシュされたデータを、ダンプおよびリストアできるようになりました。MySQLサーバーの再起動時に自動で実行するよう設定することも、任意のタイミングで実施することも可能です。ダンプされるデータは、テーブルスペースとページの情報のみと非常に小さいサイズのため、空き容量の心配も不要です。（"innodb_buffer_pool_dump_at_shutdown"、"innodb_buffer_pool_load_at_startup"、"SET GLOBAL innodb_buffer_pool_dump_now"、"SET GLOBAL innodb_buffer_pool_load_now"）

デッドロック

"innodb_print_all_deadlocks"パラメータが追加され、デッドロック発生時に情報をエラーログに記録しておくことが可能になりました。またデッドロック検出のアルゴリズムも変更され、検出が高速化されました。

オプティマイザ性能・ユーザビリティ向上

サブクエリ

MySQLの弱点とされていたサブクエリの性能が改善され、実行速度が大幅に高速化されました。

BNLJ

Block Nested Loop Join（BNLJ）が、これまでのINNER JOINに加えOUTER JOINにも対応し、インデックスが使えないJOIN処理の更なる高速化が可能となりました。

BKA、MRR

バッチキーアクセス（BKA）とマルチレンジリード（MRR）というアルゴリズムが追加され、ディスクアクセスの多いJOIN処理の高速化が可能となりました。

ICP

Index Condition Pushdown（ICP）というアルゴリズムが追加され、WHERE句の条件などのインデックスによる絞り込みを全てストレージエンジン側で行うことで、MySQLサーバー内のオーバーヘッド削減を図ります。（InnoDB、MyISAM、NDBCLUSTER）

LIMIT句

LIMIT句のファイルソート（ORDER BY non_indexed_column LIMIT x）が最適化され、x個のレコードがソートバッファに収まる場合の処理速度向上が可能となりました。

FROM句

FROM句にビュー/サブクエリが含まれるクエリを高速化できるようになりました。

Explain

これまでのSELECTに加え、DELETE、INSERT、REPLACE、UPDATEでも、Explainを使って実行計画を確認することが可能になりました。また、従来のテキストフォーマットに加え、JSONフォーマットでもExplainを取得することが可能になり、MySQL Workbenchと連携することでビジュアルでの確認もできるようになりました。

トレース

オプティマイザが実行計画を生成する際にどのような判断をしたのか、JSON形式で出力された詳細を追跡できるようになりました。

NoSQL API（InnoDB memcached plugin）

InnoDB memcached pluginは、SQLを使わず、memcached互換のプロトコルを使用してInnoDBのデータへアクセスするために開発されたプラグインです。SQLを使うよりも処理が高速化されることが特徴です。
単純なデータの追加処理の場合、SQLのINSERTコマンドとmemcachedプロトコルのSETコマンドでは、memcachedプロトコルの方が約9倍も多くの処理が可能と言われています。
また、同一のデータに対して、SQLとmemcachedの両立が可能なため、JOINなどの複雑な作業が必要な場合のみSQLを使う、といったそれぞれのメリットを生かした使い方が可能です。

レプリケーション性能・耐障害性向上

バイナリログ

"binlog_row_image"パラメータを"minimal"にセットすることで、バイナリログのサイズを削減できるようになりました。minimal指定時は、変更後の行イメージには、変更された列のイメージのみを保持します。これにより、レプリケーション環境におけるメモリ使用量やネットワーク転送量、ディスク使用量の削減が可能となり、ひいてはパフォーマンスの改善にもつながります。

グループコミット

複数トランザクションの情報を、グループコミットにより、まとめて1回のI/Oでディスクにフラッシュできるようになりました。これにより、"sync_binlog=1"指定時の大幅なオーバーヘッド削減が実現されました。

マルチスレッドスレーブ

マルチスレッドスレーブを使用することで、スレーブ側の処理もマルチスレッドで実行できるようになったため、スレーブの遅延改善が見込めます。ただし、MySQL5.6の段階ではまだ制限もあるため、本格的な活用は5.7からとなりそうです。

GTID

トランザクションを一意に識別できる識別子とし、GTID（グローバルトランザクションID）が追加されました。これにより、スレーブを新規マスターに昇格させる際などに、ポジション情報の確認をする必要がなくなり、複数台でレプリケーションを構成している場合の運用管理が簡素化されます。

クラッシュセーフスレーブ

ポジション情報をInnoDB上のテーブルに記録することで、データの変更とポジション情報の変更の整合性を保つことが可能になりました。これにより、クラッシュセーフなスレーブが実現されます。（"relay_log_info_repository"、"relay_log_recovery"）

チェックサム

バイナリログにチェックサムが追加されました。デフォルトで追加されている状態です。（"binlog_checksum"）

遅延レプリケーション

マスターからスレーブへのレプリケーションを、意図的に遅延させることが可能となりました。遅延は、秒単位で指定できます。複数台のスレーブが存在する場合、特定のスレーブのみ遅延させることも可能なため、データ消失時の復旧用や故意的なシステムテスト用など、いろいろな用途が考えられます。

サーバーUUID

Universally Unique Identifier （UUID）というユニークなIDがサーバー毎に自動で割り振られるようになりました。SHOW SLAVE STATUSのMaster_UUIDからマスターを一意に識別したり、といった使用が可能です。リモートで監視しているサーバーやバーチャルIPアドレスを使用しているサーバーで活用できます。

情報ログイベント

レプリケーションの追跡やデバッグを強化するため、RBR使用時に、オリジナルSQL文に関する情報をバイナリログに追加できるようになりました。（"binlog_rows_query_log_events"）

NIC

バイナリログの転送による帯域枯渇への対策として、スレーブサーバーが複数のNICを持っている場合、レプリケーション用のNICを明示的に指定できるようになりました。これにより、マスターとの接続に使用する通信を分けることが可能なため、レプリケーションの安定運用が実現されます。

リモートバイナリログバックアップ

運用性を向上させるため、mysqlbinglogコマンドを使って、リモートサーバーのバイナリログをコピーできるようになりました。自ノード内でコピーするよう設定も可能なため、ディスク障害に備えたバイナリログのバックアップという目的でも使用できます。

パフォーマンススキーマの改善

MySQL5.5から実装されたパフォーマンススキーマ（PERFORMANCE_SCHEMA）が、一般のDB管理者でもモニタリングやチューニングに活用できるよう、大幅に改良されました。MySQL5.6ではデフォルトで、パフォーマンススキーマが有効になっています。
performance_schemaスキーマ内の各種テーブル（"_current"、"_summary"など）をSELECTし、実行に時間が掛かっているSQLを特定するなど、効率的に稼働統計を確認することが可能です。