Documentation Home
MySQL 5.6 リファレンスマニュアル
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb
MySQL 5.6 リファレンスマニュアル  /  一般情報  /  MySQL 5.6 の新機能

1.4 MySQL 5.6 の新機能

このセクションでは、MySQL 5.6 で追加された機能、非推奨になった機能、および削除された機能について要約しています。

追加された機能

次の機能が、MySQL 5.6 に追加されました。

  • セキュリティーの改善  次のセキュリティーの改善が行われました。

    • MySQL に、.mylogin.cnf という名前のオプションファイルに認証証明書を暗号化して格納する方法が用意されました。このファイルを作成するには、mysql_config_editor ユーティリティーを使用します。MySQL クライアントプログラムがあとからこのファイルを読み取って、MySQL Server に接続するための認証証明書を取得することができます。mysql_config_editor は、暗号化を使用して .mylogin.cnf ファイルを作成するため、証明書は平文として格納されず、その内容はクライアントプログラムによって復号化されると、メモリー内でのみ使用されます。このように、パスワードは平文でない形式でファイルに格納でき、コマンド行または環境変数で表示する必要もなくあとから使用できます。詳細は、セクション4.6.6「mysql_config_editor — MySQL 構成ユーティリティー」を参照してください。

    • MySQL は、SHA-256 パスワードハッシングを実装する sha256_password という名前の認証プラグインを通じて利用できる、ユーザーアカウントパスワードのより強力な暗号化をサポートするようになりました。このプラグインは組み込まれているため、常に使用でき、明示的にロードする必要はありません。SHA-256 パスワードを使用するアカウントを作成する手順などの詳細は、セクション6.3.8.4「SHA-256 認証プラグイン」を参照してください。

    • mysql.user テーブルに password_expired カラムが追加されました。そのデフォルト値は 'N' ですが、新しい ALTER USER ステートメントでは 'Y' に設定できます。アカウントのパスワードの有効期限が切れたあと、そのアカウントを使用したサーバーへの以降の接続で操作を実行すると、ユーザーが SET PASSWORD ステートメントを発行して、新しいアカウントパスワードを確立するまで、すべての場合でエラーになります。詳細は、セクション13.7.1.1「ALTER USER 構文」およびセクション6.3.6「パスワードの期限切れとサンドボックスモード」を参照してください。

    • MySQL にはパスワードセキュリティーのチェック対策が施されました。

      • 平文の値として指定されるパスワードを割り当てるステートメントで、値は現在のパスワードポリシーと照合して検査され、弱い場合は拒否されます (ステートメントは ER_NOT_VALID_PASSWORD エラーを返します)。これは、CREATE USER、GRANT、および SET PASSWORD ステートメントに影響します。PASSWORD() および OLD_PASSWORD() 関数への引数として指定されるパスワードも検査されます。

      • パスワード候補の強度は、新しい VALIDATE_PASSWORD_STRENGTH() SQL 関数を使用して評価できます。これは、パスワード引数を取得して、0 (弱い) から 100 (強い) の整数を返します。

      どちらの機能も validate_password プラグインで実装されます。詳細は、セクション6.1.2.6「パスワード検証プラグイン」を参照してください。

    • mysql_upgrade は、4.1 以前の古いハッシング方法でハッシングされたパスワードを持つユーザーアカウントを見つけた場合、警告を発するようになりました。このようなアカウントは、よりセキュアなパスワードハッシングを使用するように更新する必要があります。セクション6.1.2.4「MySQL でのパスワードハッシュ」を参照してください。

    • Unix プラットフォームでは、mysql_install_db は、よりセキュアな MySQL インストールを実現する新しいオプションである --random-passwords をサポートします。--random-passwords を付けて mysql_install_db を呼び出すと、ランダムパスワードが MySQL root アカウントに割り当てられ、これらのアカウントに対して「有効期限切れパスワード」フラグが設定され、匿名ユーザー MySQL アカウントが削除されます。追加情報についてはセクション4.4.3「mysql_install_db — MySQL データディレクトリの初期化」を参照してください。

    • パスワードが平文で一般クエリーログ、スロークエリーログ、およびバイナリログに書き込まれたステートメントに表示されないように、ロギングが変更されました。セクション6.1.2.3「パスワードおよびロギング」を参照してください。

      mysql クライアントは、パスワードを参照するその履歴ファイルステートメントに記録しないようになりました。セクション4.5.1.3「mysql のロギング」を参照してください。

    • START SLAVE 構文は、マスターへの接続に接続パラメータを指定できるように変更されました。これは、master.info ファイルにパスワードを格納する代替方法になります。セクション13.4.2.5「START SLAVE 構文」を参照してください。

  • MySQL Enterprise  監査ログプラグインで生成されたファイルの形式は、Oracle Audit Vault との互換性が高くなるように変更されました。セクション6.3.12「MySQL Enterprise Audit ログプラグイン」およびセクション6.3.12.3「監査ログファイル」を参照してください。

    MySQL Enterprise Edition には、SQL レベルでの OpenSSL 機能を公開している OpenSSL ライブラリに基づいて、一連の暗号化関数が含まれるようになりました。これらの関数を使用することによって、エンタープライズアプリケーションが次の操作を実行できるようになります。

    • 公開鍵非対称暗号方式を使用した、追加のデータ保護の実装

    • 公開鍵、秘密鍵、およびデジタル署名の作成

    • 非対称暗号化および非対称復号化の実行

    • デジタル署名およびデータの検証や妥当性検査に対する暗号化ハッシュの使用

    詳細は、セクション12.17「MySQL Enterprise Encryption の関数」を参照してください。

    MySQL Enterprise Edition に含まれる監査ログプラグインには、ユーザーアカウントおよびイベントステータスに基づいて監査イベントをフィルタリングする機能が用意されました。複数の新しいシステム変数は、DBA にフィルタリング制御をもたらします。さらに、複数のステータス変数の追加によって、監査ログプラグインレポート機能が改善されました。詳細は、セクション6.3.12.4「監査ログプラグインのロギング制御」およびセクション6.3.12.7「監査ログプラグインのステータス変数」を参照してください。

  • サーバーデフォルトに対する変更  MySQL 5.6.6 以降では、MySQL Server のいくつかのデフォルトパラメータが、前のリリースのデフォルト値と異なっています。これらの変更の目的は、初期設定のままで優れたパフォーマンスを提供し、データベース管理者が設定を手動で変更することの必要性を低下させることです。詳細は、セクション5.1.2.1「サーバーのデフォルト値への変更」を参照してください。

  • InnoDB の拡張機能  次の InnoDB の拡張機能が追加されました。

    • InnoDB テーブル上に FULLTEXT インデックスを作成し、MATCH() ... AGAINST 構文を使用してそれらのクエリーを実行できます。この機能には、新しい近似検索演算子 (@) と、複数の新しい構成オプションおよび INFORMATION_SCHEMA テーブルが含まれます。詳細は、セクション14.2.13.3「FULLTEXT インデックス」を参照してください。

    • テーブルをコピーせず、テーブルへの挿入、更新、および削除をブロックせず、またはその両方を行わずに、複数の ALTER TABLE 操作を実行できます。これらの拡張機能はまとめて、オンライン DDL と呼ばれています。詳細は、セクション14.11「InnoDB とオンライン DDL」を参照してください。

    • InnoDB は、MySQL データディレクトリ外の場所で InnoDB file-per-table テーブルスペース (.ibd ファイル) を作成できるようにする、CREATE TABLE ステートメントの DATA DIRECTORY='directory' 句をサポートするようになりました。この拡張機能は、サーバー環境により適切に適合する場所に file-per-table テーブルスペースを作成できる柔軟性をもたらします。たとえば、ビジーテーブルを SSD デバイス上に、または大きなテーブルを大容量 HDD デバイス上に配置できます。

      詳細は、セクション14.5.4「テーブルスペースの位置の指定」を参照してください。

    • InnoDB は、「トランスポータブルテーブルスペース」の概念をサポートするようになり、バッファーされたデータ、進行中のトランザクション、およびスペース ID や LSN などの内部管理詳細によって不整合や不一致が起きることなく、実行中の MySQL インスタンスから file-per-table テーブルスペース (.ibd ファイル) をエクスポートし、別の実行中のインスタンスにインポートできます。

      FLUSH TABLE コマンドの FOR EXPORT 句は、未保存のあらゆる変更内容を InnoDB メモリーバッファーから .ibd ファイルに書き込みます。.ibd ファイルと個別のメタデータファイルを別のサーバーにコピーしたあと、ALTER TABLE ステートメントの DISCARD TABLESPACE 句と IMPORT TABLESPACE 句が、別の MySQL インスタンスにテーブルデータをもたらすために使用されます。

      この拡張機能は、サーバー環境により適切に適合できるように、file-per-table テーブルスペースを自由に移動できる柔軟性をもたらします。たとえば、ビジーテーブルを SSD デバイス上に、または大きなテーブルを大容量 HDD デバイス上に移動できます。詳細は、セクション14.5.5「テーブルスペースの別のサーバーへのコピー (トランスポータブルテーブルスペース)」を参照してください。

    • 非圧縮テーブルの InnoDB ページサイズを、デフォルトの 16K バイトに代わるサイズとして、8K バイトまたは 4K バイトに設定できるようになりました。この設定は、innodb_page_size 構成オプションで制御されます。このサイズは MySQL インスタンスの作成時に指定します。インスタンス内のすべての InnoDB テーブルスペースは同じページサイズを共有します。ページサイズが小さくなると、ワークロードとストレージデバイスとの特定の組み合わせ、特にブロックサイズの小さな SSD デバイスとの組み合わせについて、冗長または非効率的な I/O を回避できるようになります。

    • 適応型フラッシュのアルゴリズムに対する改善により、さまざまなワークロード下での I/O 操作の効率性と整合性が向上します。新しいアルゴリズムとデフォルトの構成値は、ほとんどのユーザーにとって、パフォーマンスと並列性を改善すると考えられています。上級ユーザーは、複数の構成オプションを通じて、I/O 応答性を微調整できます。詳細は、セクション14.13.1.6「InnoDB バッファープールのフラッシュのチューニング」を参照してください。

    • NoSQL スタイルの API を通じて、InnoDB テーブルにアクセスする MySQL アプリケーションをコード化できます。この機能は、普及している memcached デーモンを使用して、鍵と値のペアに ADD、SET、GET などのリクエストをリレーします。データを格納および取得するこれらの単純な操作により、クエリー実行計画の解析や構築などの SQL オーバーヘッドが回避されます。NoSQL API および SQL を通じて同じデータにアクセスできます。たとえば、高速な更新および検索に NoSQL API を、複雑なクエリーおよび既存のアプリケーションとの互換性に SQL を使用できます。詳細は、セクション14.18「InnoDB と memcached の統合」を参照してください。

    • InnoDB テーブルのオプティマイザ統計は、より予測可能な間隔で収集され、サーバーの再起動にまたがって維持でき、計画安定性が向上します。オプティマイザ統計の精度を高め、クエリー実行計画を改善するように、InnoDB インデックスに対して行われるサンプル収集の量を制御することもできます。詳細は、セクション14.13.16.1「永続的オプティマイザ統計のパラメータの構成」を参照してください。

    • 新しい最適化は、読み取り専用のトランザクションに適用され、アドホッククエリーとレポート生成アプリケーションのパフォーマンスと並列性を改善します。可能な場合にはこれらの最適化は自動的に適用されます。または、START TRANSACTION READ ONLY を指定してトランザクションが読み取り専用になるようにすることができます。詳細は、セクション14.13.14「InnoDB の読み取り専用トランザクションの最適化」を参照してください。

    • InnoDB Undo ログを、システムテーブルスペースから 1 つ以上の個別のテーブルスペースに移動できます。Undo ログの I/O パターンは、ハードディスクストレージにシステムテーブルスペースを保持しながら、これらの新しいテーブルスペースを、SSD ストレージに移動する適切な候補にします。詳細は、セクション14.5.6「個別のテーブルスペースへの InnoDB Undo ログの格納」を参照してください。

    • より高速なチェックサムアルゴリズムを有効にする構成オプション innodb_checksum_algorithm=crc32 を指定することによって、InnoDB チェックサム機能の効率性を改善できます。このオプションは innodb_checksums オプションを置き換えます。古いチェックサムアルゴリズム (オプション値 innodb) を使用して書き込まれたデータは完全に上方互換性があります。新しいチェックサムアルゴリズム (オプション値 crc32) を使用して変更されたテーブルスペースは、innodb_checksum_algorithm オプションをサポートしない以前のバージョンの MySQL にダウングレードできません。

    • InnoDB Redo ログファイルの最大合計サイズは、4G バイトから 512G バイトに増大しました。innodb_log_file_size オプションで、さらに大きな値を指定できます。既存の Redo ログファイルのサイズが innodb_log_file_size および innodb_log_files_in_group で指定されたサイズと一致しない状況を、起動動作で自動処理するようになりました。

    • --innodb-read-only オプションを使用すると、MySQL Server を読み取り専用モードで実行できます。DVD や CD などの読み取り専用メディア上の InnoDB テーブルにアクセスすることも、すべて同じデータディレクトリを共有する複数のインスタンスを含むデータウェアハウスを設定できます。使用法の詳細は、セクション14.3.1「読み取り専用操作用の InnoDB の構成」を参照してください。

    • 新しい構成オプション innodb_compression_level では、zlib で使用する 0-9 の範囲から、InnoDB 圧縮テーブルの圧縮レベルを選択できます。更新操作によってページが再度圧縮されるときに、バッファープール内の圧縮ページが Redo ログに格納されるかどうかを制御することもできます。この動作は、innodb_log_compressed_pages 構成オプションで制御されます。

    • InnoDB 圧縮テーブル内のデータブロックには、一定量の空スペース (パディング) が含まれ、DML 操作は、新しい値を再圧縮することなく、行データを変更できます。パディングが多すぎると、大きな変更後にデータを再圧縮する必要があるときに、圧縮が失敗する可能性が増え、ページの分割が必要になる可能性があります。パディングの量を動的に調整できるようになったため、DBA は、新しいパラメータでテーブル全体を再作成したり、ページサイズの異なるインスタンス全体を再作成したりすることなく、圧縮の失敗の割合を低減できるようになりました。関連した新しい構成オプションは、innodb_compression_failure_threshold_pct、innodb_compression_pad_pct_max です。

    • 複数の新しい InnoDB 関連の INFORMATION_SCHEMA テーブルは、InnoDB バッファープールに関する情報、テーブル、インデックス、および InnoDB データディクショナリからの外部キーに関するメタデータ、パフォーマンススキーマテーブルからの情報を補完するパフォーマンスメトリックに関する低レベル情報を提供します。

    • 膨大な数のテーブルを含むシステムでのメモリーロードを簡単にするために、InnoDB は、もっとも長い間アクセスされずに経過したテーブルを選択する LRU アルゴリズムを使用して、開いているテーブルに関連付けられたメモリーを解放するようになりました。開いた InnoDB テーブルのメタデータを保持するためにより多くのメモリーを予約するには、table_definition_cache 構成オプションの値を増やしてください。InnoDB は、InnoDB データディクショナリキャッシュ内の開いているテーブルインスタンスの数に関する「ソフト制限」として、この値を扱います。追加情報については、table_definition_cache のドキュメントを参照してください。

    • InnoDB には、カーネルミューテックスの分割による競合の軽減、メインスレッドから個別のスレッドへのフラッシュ操作の移動、複数のパージスレッドの有効化、大容量メモリーシステムでのバッファープールの競合の軽減などの、複数の内部パフォーマンス拡張機能があります。

    • InnoDB は、高速な新しいアルゴリズムを使用して、deadlocks を検出します。すべての InnoDB デッドロックに関する情報は、MySQL Server エラーログに書き込むことができ、アプリケーション問題の診断に役立ちます。

    • サーバー再起動後の長時間のウォームアップを回避するために、特に大きな InnoDB バッファープールを伴うインスタンスの場合は、再起動直後にバッファープールにページをリロードできます。MySQL は、シャットダウン時にコンパクトなデータファイルをダンプし、続いてそのデータファイルを参照して、次回の再起動時にリロードするページを見つけることができます。ベンチマーキング中や複雑なレポート生成クエリー後など、いつでもバッファープールを手動でダンプまたはリロードすることもできます。詳細は、セクション14.13.1.5「再起動を高速化するための InnoDB バッファープールのプリロード」を参照してください。

    • MySQL 5.6.16 以降、innochecksum は 2G バイト以上のサイズのファイルのサポートに対応しています。以前は、innochecksum は 2G バイトまでのサイズのファイルだけをサポートしていました。

    • MySQL 5.6.16 以降では、新しいグローバル構成パラメータ innodb_status_output および innodb_status_output_locks を使用すると、標準の InnoDB Monitor および InnoDB Lock Monitor を動的に有効および無効にすることができます。特別な名前が付けられたテーブルを作成および削除することによって、定期的な出力のモニターを有効および無効にする方法は非推奨であり、今後のリリースで削除される可能性があります。追加情報については、セクション14.15「InnoDB モニター」を参照してください。

    • MySQL 5.6.17 以降、MySQL は、次の操作にオンライン DDL (ALGORITHM=INPLACE) を使用した通常のパーティション化された InnoDB テーブルの再構築をサポートします。

      • OPTIMIZE TABLE

      • ALTER TABLE ... FORCE

      • ALTER TABLE ... ENGINE=INNODB (InnoDB テーブルで実行した場合)

      オンライン DDL のサポートにより、テーブル再構築時間が短縮し、ユーザーアプリケーションの停止時間の短縮に役立つ並列 DML が可能になります。詳細は、セクション14.11.1「オンライン DDL の概要」を参照してください。

  • パーティション化  次のテーブルパーティション化拡張機能が追加されました。

    • パーティションの最大数は 8192 まで増加しています。これは、テーブルのすべてのパーティションとすべてのサブパーティションを含めた数字です。

    • ALTER TABLE ... EXCHANGE PARTITION ステートメントを使用して、パーティション化されたテーブルのパーティションまたはサブパーティション化されたテーブルのサブパーティションを、パーティション化されていないことを除けば同じ構造のテーブルと交換できるようになりました。これはたとえば、パーティションのインポートおよびエクスポートに使用できます。詳細および例については、セクション19.3.3「パーティションとサブパーティションをテーブルと交換する」を参照してください。

    • パーティション化されたテーブルで機能するクエリーや多数のデータ変更ステートメントで、1 つ以上のパーティションまたはサブパーティションの明示的な選択がサポートされるようになりました。たとえば、整数カラム c を含むテーブル t に、p0、p1、p2、および p3 という名前の 4 つのパーティションがあるとします。この場合、クエリー SELECT * FROM t PARTITION (p0, p1) WHERE c < 5 は、パーティション p0 および p1 から、c が 5 未満である行だけを返します。

      次のステートメントは、明示的なパーティション選択をサポートします。

      • SELECT

      • DELETE

      • INSERT

      • REPLACE

      • UPDATE

      • LOAD DATA。

      • LOAD XML。

      構文については、個々のステートメントの説明を参照してください。追加情報および例については、セクション19.5「パーティション選択」を参照してください。

    • パーティションロックプルーニングは、多くのパーティションを含むテーブル上で機能する多数の DML および DDL ステートメントのパフォーマンスを大幅に改善しますが、これは、これらのステートメントの影響を受けないパーティション上のロックを除去できるようにすることによって行います。このようなステートメントには、SELECT、SELECT ... PARTITION、UPDATE、REPLACE、INSERT などの多数のステートメントが含まれます。この結果パフォーマンスが改善されたステートメントの全リストなどの詳細は、セクション19.6.4「パーティショニングとロック」を参照してください。

  • パフォーマンススキーマ  パフォーマンススキーマには、次のような複数の新機能が含まれています。

    • テーブル入力および出力のインストゥルメンテーション。インストゥルメントされた操作には、永続的ベーステーブルまたは一時テーブルへの行レベルのアクセスが含まれます。行に影響する操作は、フェッチ、挿入、更新、および削除です。

    • スキーマ名またはテーブル名に基づいた、テーブルによるイベントフィルタリング。

    • スレッドによるイベントフィルタリング。スレッドに関する詳細が収集されます。

    • テーブルおよびインデックス I/O 用とテーブルロック用のサマリーテーブル。

    • ステートメントとステートメント内のステージのインストゥルメンテーション。

    • サーバーの起動時のインストゥルメントとコンシューマの構成。以前は実行時にのみ可能でした。

  • MySQL Cluster  MySQL Cluster は個別の製品としてリリースされます。最新の GA リリースは MySQL 5.6 に基づき、バージョン 7.3 の NDB ストレージエンジンを使用しています。クラスタリングのサポートは、主要な MySQL Server 5.6 リリースでは利用できません。MySQL Cluster NDB 7.3 の詳細は、第18章「MySQL Cluster NDB 7.3 および MySQL Cluster NDB 7.4」を参照してください。最新の開発バージョンは、バージョン 7.4 の NDB ストレージエンジンと MySQL Server 5.6 に基づいた、MySQL Cluster NDB 7.4 です。現在、MySQL Cluster NDB 7.4 はテストおよび評価のために使用できます。最新の MySQL Cluster NDB 7.4 リリースは https://dev.mysql.com/downloads/cluster/ から入手できます。

    詳細および MySQL Cluster NDB 7.4 で行われた改善の概要については、セクション18.1.4.2「MySQL Cluster NDB 7.4 での MySQL Cluster の開発」を参照してください。

    以前の GA リリースである MySQL Cluster NDB 7.2 は、MySQL Server 5.5 に基づき、まだ製造され利用可能ですが、新しい配備には MySQL Cluster NDB 7.3 を使用することをお勧めします。MySQL Cluster NDB 7.2 の詳細は、MySQL NDB Cluster 7.2を参照してください。

    MySQL Cluster NDB 7.1 もまだ利用可能でサポート対象です (ただし新しい配備には、最新の GA リリースシリーズ、現在では MySQL Cluster NDB 7.3 を使用することをお勧めします)。これらのバージョンの MySQL Cluster は MySQL Server 5.1 に基づいており、『MySQL 5.1 マニュアル』に記載されています。詳細は、https://dev.mysql.com/doc/refman/5.1/en/mysql-cluster.htmlを参照してください。

  • レプリケーションとロギング  次のレプリケーション拡張機能が追加されました。

    • MySQL は、グローバルトランザクション識別子 (「GTID」とも呼ばれます) を使用したトランザクションベースのレプリケーションをサポートするようになりました。これにより、発信サーバー上でコミットされ、いずれかのスレーブによって適用されたときに、各トランザクションの識別と追跡が可能になります。

      レプリケーションの設定で GTID を有効にする場合、主に --gtid-mode および --enforce-gtid-consistency の新しいサーバーオプションを使用して行います。GTID のサポートで導入された追加オプションおよび変数の詳細は、セクション17.1.4.5「グローバルトランザクション ID のオプションと変数」を参照してください。

      GTID を使用する場合、新しいスレーブを開始したり、新しいマスターにフェイルオーバーするときに、ログファイルやこれらのファイル内での位置を参照したりする必要はありません。このため、これらのタスクが非常に簡略化されます。バイナリログファイルを参照して、または参照せずに、GTID レプリケーションに対してサーバーをプロビジョニングする場合の詳細は、セクション17.1.3.3「フェイルオーバーおよびスケールアウトでの GTID の使用」を参照してください。

      GTID ベースのレプリケーションは完全にトランザクションベースであるため、マスターとスレーブの一貫性のチェックが簡単になります。所定のマスター上でコミットされたすべてのトランザクションが、所定のスレーブ上でもコミットされている場合、2 台のサーバー間の一貫性は保証されます。

      MySQL Replication での GTID の実装および使用についてさらに詳しい情報が必要な場合は、セクション17.1.3「グローバルトランザクション識別子を使用したレプリケーション」を参照してください。

    • MySQL の行ベースのレプリケーションは、行イメージコントロールをサポートするようになりました。各行の変更に対し、すべてのカラムではなく、それぞれの行での変更を一意に識別および実行するために必要なカラムだけを記録することによって、ディスク容量、ネットワークリソース、およびメモリー使用量を節約できます。binlog_row_image サーバーシステム変数を、minimal (必要なカラムだけを記録)、full (すべてのカラムを記録)、noblob (不要な BLOB または TEXT カラムを除いたすべてのカラムを記録) のいずれかの値に設定することによって、すべての行を記録するか、最低限の行を記録するかを指定できます。詳細は、バイナリロギングで使用されるシステム変数を参照してください。

    • MySQL Server で書き込まれ、読み取られるバイナリログは、完全なイベント (トランザクション) だけが記録されたり読み戻されたりするため、クラッシュセーフになりました。デフォルトで、サーバーはイベント自体のほかにイベントの長さを記録し、この情報を使用して、イベントが正しく書き込まれたことを検証します。binlog_checksum システム変数を設定することによって、サーバーで、CRC32 チェックサムを使用してイベントのチェックサムを書き込ませることもできます。サーバーにバイナリログからチェックサムを読み取らせるには、master_verify_checksum システム変数を使用します。--slave-sql-verify-checksum システム変数は、スレーブ SQL スレッドに、リレーログからチェックサムを読み取らせます。

    • MySQL は、テーブルおよびファイルへのマスター接続情報のロギングと、スレーブリレーログ情報のロギングをサポートするようになりました。これらのテーブルの使用は、--master-info-repository と --relay-log-info-repository のサーバーオプションによって別々に制御できます。--master-info-repository を TABLE に設定すると、接続情報が slave_master_info テーブルに記録されます。--relay-log-info-repository を TABLE に設定すると、リレーログ情報が slave_relay_log_info テーブルに記録されます。これらのテーブルはどちらも、mysql システムデータベース内に自動的に作成されます。

      レプリケーションをクラッシュセーフにするには、slave_master_info テーブルと slave_relay_log_info テーブルがそれぞれ、トランザクションストレージエンジンを使用する必要があります。この理由のため、MySQL 5.6.6 以降では、これらのテーブルは InnoDB を使用して作成されます。(Bug #13538891) これらの両方のテーブルで MyISAM を使用している以前の MySQL 5.6 リリースを使用している場合は、レプリケーションがクラッシュセーフであることを望むならば、レプリケーションを開始する前に、両方をトランザクションストレージエンジン (InnoDB など) に変換する必要があることになります。このような場合は、適切な ALTER TABLE ... ENGINE=... ステートメントを使用して、これを行えます。レプリケーションが実際に実行している間、これらのテーブルのどちらかが使用するストレージエンジンを変更しようとしないでください。

      詳細は、クラッシュセーフレプリケーションを参照してください。

    • mysqlbinlog には、そのオリジナルのバイナリ形式でバイナリログをバックアップする機能が用意されました。mysqlbinlog は、--read-from-remote-server オプションと --raw オプションを付けて呼び出された場合、サーバーに接続し、ログファイルをリクエストし、元のファイルと同じ形式で出力ファイルを書き込みます。セクション4.6.8.3「バイナリログファイルのバックアップのための mysqlbinlog の使用」を参照してください。

    • MySQL は、スレーブサーバーが少なくとも指定した時間だけ意図的にマスターに遅れるような遅延レプリケーションをサポートするようになりました。デフォルトの遅延は 0 秒です。CHANGE MASTER TO の新しい MASTER_DELAY オプションを使用して、遅延を設定します。

      遅延レプリケーションは、マスターでのユーザーの誤りから保護したり (DBA は遅延スレーブを災害の直前の時間までロールバックできます)、遅れがあるときのシステムの動作をテストしたりするなどの目的に使用できます。セクション17.3.9「遅延レプリケーション」を参照してください。

    • CHANGE MASTER TO ステートメントの発行時に MASTER_BIND オプションを使用することによって、複数のネットワークインタフェースがあるレプリケーションスレーブに、これらのうち 1 つだけを使用させられるようになりました。

    • log_bin_basename システム変数が追加されました。この変数には、完全なファイル名と、バイナリログファイルへのパスが含まれます。log_bin システム変数はバイナリロギングが有効かどうかだけを示しますが、log_bin_basename は --log-bin サーバーオプションで設定された名前を反映します。

      同様に、relay_log_basename システム変数は、ファイル名と、リレーログファイルへの完全パスを示します。

    • MySQL Replication は、スレーブ上でのマルチスレッドを使用したトランザクションの並列実行をサポートするようになりました。並列実行が有効な場合、スレーブ SQL スレッドは、slave_parallel_workers サーバーシステム変数の値によって決定される、多数のスレーブワーカースレッドに対する調整役として機能します。スレーブでのマルチスレッドの現在の実装は、データと更新がデータベースごとにパーティション化されていることと、所定のデータベース内の更新が、マスター上の場合と同じ相対的順序で行われることを前提としています。ただし、異なるデータベース間でトランザクションを調整する必要はありません。この場合、トランザクションもデータベースごとに配分できます。つまり、スレーブ上のワーカースレッドは、別のデータベースへの更新が完了するまで待機せずに、所定のデータベースで連続してトランザクションを処理できます。

      別々のデータベースに対するトランザクションは、スレーブとマスターとでは実行順序が異なることがあるため、単に直近で実行したトランザクションを確認するだけでは、マスター上の以前のすべてのトランザクションがスレーブ上で実行されたという保証にはなりません。これは、マルチスレッド化したスレーブを使用する場合にロギングとリカバリに影響します。スレーブ上でマルチスレッドを使用したときにバイナリロギング情報をどのように解釈すればよいかについては、セクション13.7.5.35「SHOW SLAVE STATUS 構文」を参照してください。

  • オプティマイザの拡張機能  クエリーオプティマイザで次の改善が実装されました。

    • オプティマイザは、次の形式のクエリー (およびサブクエリー) をより効率よく処理できるようになりました。 

      SELECT ... FROM single_table ... ORDER BY non_index_column [DESC] LIMIT [M,]N;

      この種のクエリーは、大きな結果セットの数行だけを表示する Web アプリケーションで一般的なものです。例: 

      SELECT col1, ... FROM t1 ... ORDER BY name LIMIT 10;
SELECT col1, ... FROM t1 ... ORDER BY RAND() LIMIT 15;

      ソートバッファーには、sort_buffer_size のサイズが入ります。N 行のソート要素が、ソートバッファー (M が指定された場合は M+N 行) に収まる程度に小さい場合は、サーバーはマージファイルの使用を避けて、メモリー内全体でソートを実行できます。詳細は、セクション8.2.1.19「LIMIT クエリーの最適化」を参照してください。

    • オプティマイザは、Disk-Sweep Multi-Range Read を実装します。セカンダリインデックスでの範囲スキャンを使用して行を読み取ると、テーブルが大きく、ストレージエンジンのキャッシュに格納されていない場合、ベーステーブルへのランダムディスクアクセスが多発する結果になることがあります。Disk-Sweep Multi-Range Read (MRR) 最適化を使用すると、MySQL は、最初にインデックスだけをスキャンし、該当する行のキーを収集することによって、範囲スキャンのランダムディスクアクセスの回数を軽減しようとします。続いてキーがソートされ、最後に主キーの順序を使用してベーステーブルから行が取得されます。Disk-Sweep MRR の目的は、ランダムディスクアクセスの回数を減らし、その代わりに、ベーステーブルデータの順次スキャンを増やすことです。詳細は、セクション8.2.1.13「Multi-Range Read の最適化」を参照してください。

    • オプティマイザは、MySQL がインデックスを使用してテーブルから行を取得する場合の最適化として、Index Condition Pushdown (ICP) を実装します。ICP を使用しない場合、ストレージエンジンはインデックスをトラバースして、ベーステーブル内で行を検索し、MySQL Server に返し、MySQL Server が行に対して WHERE 条件を評価します。ICP を有効にすると、インデックスからのフィールドだけを使用して WHERE 条件の部分を評価できる場合は、MySQL Server はこの WHERE 条件の部分をストレージエンジンにプッシュダウンします。ストレージエンジンは続いて、インデックスエントリを使用することによって、プッシュされたインデックス条件を評価し、これが満たされた場合にのみ、ベース行が読み取られます。ICP は、ストレージエンジンがベーステーブルに対して行う必要のあるアクセスの回数と、MySQL Server がストレージエンジンに対して行う必要のあるアクセスの回数を軽減できます。詳細は、セクション8.2.1.6「インデックスコンディションプッシュダウンの最適化」を参照してください。

    • EXPLAIN ステートメントは、DELETE、INSERT、REPLACE、および UPDATE のステートメントの実行プラン情報を提供するようになりました。以前には、EXPLAIN は SELECT ステートメントの情報だけを提供していました。さらに、EXPLAIN ステートメントは JSON 形式で出力を生成できるようになりました。セクション13.8.2「EXPLAIN 構文」を参照してください。

    • FROM 句内でのサブクエリー (つまり派生テーブル) のオプティマイザによる処理の効率性が向上しました。FROM 句内のサブクエリーのマテリアライズはクエリー実行中にその内容が必要になるまで延期されるため、パフォーマンスが向上します。さらに、クエリー実行中に、オプティマイザは派生テーブルにインデックスを追加して、そこからの行の取得速度を上げることができます。詳細は、セクション8.2.1.18.3「FROM 句内のサブクエリー (派生テーブル) の最適化」を参照してください。

    • オプティマイザは、準結合とマテリアライズ戦略を使用して、サブクエリーの実行を最適化します。セクション8.2.1.18.1「準結合変換によるサブクエリーの最適化」およびセクション8.2.1.18.2「サブクエリー実体化によるサブクエリーの最適化」を参照してください。

    • 結合したテーブルと結合バッファーの両方にインデックスアクセスを使用する、Batched Key Access (BKA) 結合アルゴリズムが利用できるようになりました。BKA アルゴリズムは、ネスト外部結合とネスト準結合を含め、内部結合、外部結合、および準結合操作をサポートします。BKA には、テーブルスキャンの効率性の向上による結合パフォーマンスの改善というメリットもあります。詳細は、セクション8.2.1.14「Block Nested Loop 結合と Batched Key Access 結合」を参照してください。

    • オプティマイザに、主に開発者が使用するためのトレース機能が装備されました。一連の optimizer_trace_xxx システム変数と INFORMATION_SCHEMA.OPTIMIZER_TRACE テーブルによってインタフェースが提供されます。詳細については、「MySQL Internals: Tracing the Optimizer」を参照してください。

  • 条件処理  MySQL は GET DIAGNOSTICS ステートメントをサポートするようになりました。GET DIAGNOSTICS は、以前の SQL ステートメントが例外を生成したかどうかや、それが何だったかなどの情報を診断領域から取得するための標準化された方法をアプリケーションにもたらします。詳細は、セクション13.6.7.3「GET DIAGNOSTICS 構文」を参照してください。

    さらに、MySQL の動作が標準 SQL にさらに類似するように、条件ハンドラ処理ルールでの複数の欠陥が修正されました。

    • 選択するハンドラを決定するときにブロックスコープが使用されます。以前には、ストアドプログラムが、ハンドラ選択の単一のスコープを持つものとして扱われていました。

    • 条件の優先順位は、より正確に解決されるようになりました。

    • 診断領域のクリアーが変更されました。Bug #55843 のために、ハンドラを有効にする前に、処理される条件が診断領域からクリアーされていました。これにより、条件の情報がハンドラ内で利用できなくなっていました。現在、条件情報はハンドラで利用できるようになり、ハンドラは GET DIAGNOSTICS ステートメントでこの情報を調べることができます。ハンドラの実行中にまだクリアーされていない条件情報は、ハンドラが終了するときにクリアーされます。

    • 以前には、ハンドラは、条件が発生するとすぐに有効になっていました。現在、条件が発生したステートメントの実行が終了するまで有効にならず、終了した時点でもっとも適切なハンドラが選択されるようになりました。これは、ステートメントの実行中にあとから発生した条件がその前に発生した条件より高い優先順位を持ち、どちらの条件のハンドラも同じスコープにある場合、複数の条件を発生させるステートメントに影響することがあります。以前には、最初に発生した条件のハンドラが、ほかのハンドラより優先順位が低い場合でも、選択されていました。現在、優先順位がもっとも高い条件のハンドラが、ステートメントで最初に発生した条件でない場合でも、選択されるようになりました。

    詳細は、セクション13.6.7.6「ハンドラのスコープに関するルール」を参照してください。

  • データ型  次のデータ型の変更が実装されました。

    • MySQL では、マイクロ秒 (6 桁) までの精度を持つ TIME、DATETIME、および TIMESTAMP 値の小数秒に対応できるようになりました。セクション11.3.6「時間値での小数秒」を参照してください。

    • 以前には、テーブルごとに最大 1 つの TIMESTAMP カラムを自動的に初期化するか、現在の日時に更新することが可能でした。この制限は撤廃されました。どの TIMESTAMP カラム定義にも、DEFAULT CURRENT_TIMESTAMP 句と ON UPDATE CURRENT_TIMESTAMP 句の任意の組み合わせを指定できます。さらに、これらの句は、DATETIME カラム定義で使用できるようになりました。詳細は、セクション11.3.5「TIMESTAMP および DATETIME の自動初期化および更新機能」を参照してください。

    • MySQL では、TIMESTAMP データ型は、自動的な初期化および更新属性のデフォルト値と割り当ての点で、ほかのデータ型とは非標準的な方法で異なります。これらの動作はデフォルトのままですが、現在、非推奨になっており、サーバーの起動時に explicit_defaults_for_timestamp システム変数を有効にすることによってオフにすることができます。セクション11.3.5「TIMESTAMP および DATETIME の自動初期化および更新機能」およびセクション5.1.4「サーバーシステム変数」を参照してください。

  • ホストキャッシュ  MySQL では、クライアントがサーバーに接続するときに生じたエラーの原因に関する詳細が提供されるようになるとともに、クライアント IP アドレスとホスト名情報を含み DNS ルックアップを回避するために使用されるホストキャッシュへのアクセスが改善されました。次の変更が実装されました。

    • 新しい Connection_errors_xxx ステータス変数は、特定のクライアント IP アドレスに適用されない接続エラーに関する情報を提供します。

    • 特定の IP アドレスに適用されるエラーを追跡するために、ホストキャッシュにカウンタが追加され、新しい host_cache パフォーマンススキーマテーブルが、SELECT ステートメントを使用して調べられるようにホストキャッシュの内容を公開します。ホストキャッシュの内容にアクセスすると、どれだけの数のホストがキャッシュされているか、どのホストにどの種類の接続エラーが発生しているか、またはホストエラーカウントが max_connect_errors システム変数の上限にどれだけ近づいているかなどの質問に回答することができます。

    • ホストキャッシュサイズは、host_cache_size システム変数を使用して構成できるようになりました。

    詳細は、セクション8.11.5.2「DNS ルックアップの最適化とホストキャッシュ」およびセクション22.9.10.1「host_cache テーブル」を参照してください。

  • OpenGIS  OpenGIS 仕様は、2 つの幾何値の関係をテストする関数を定義します。MySQL は当初、オブジェクトバウンディング矩形を使用し、対応する MBR ベースの関数と同じ結果を返すように、これらの関数を実装しました。正確なオブジェクトの形状を使用する、対応するバージョンが利用できるようになりました。これらのバージョンの名前には ST_ プリフィクスが付けられています。たとえば、Contains() はオブジェクトバインディング矩形を使用しますが、ST_Contains() はオブジェクト形状を使用します。詳細は、セクション12.15.9「幾何オブジェクト間の空間関係をテストする関数」を参照してください。

非推奨になった機能

次の機能は、MySQL 5.6 で非推奨になり、今後のリリースで削除される可能性または予定があります。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

  • ERROR_FOR_DIVISION_BY_ZERO、NO_ZERO_DATE、および NO_ZERO_IN_DATE の SQL モードは非推奨になり、これらのいずれかを含むように sql_mode 値を設定すると警告が生成されます。MySQL 5.7 では、これらのモードは何も行いません。代わりに、その効果は、厳密 SQL モード (STRICT_ALL_TABLES または STRICT_TRANS_TABLES) の効果に含まれます。MySQL 5.7 での変更の目的は、効果が厳密モードに依存した SQL モードの数を減らし、これらを厳密モード自体の一部にすることです。

    MySQL 5.7 へのアップグレードの高度な準備を行うには、SQL Mode Changes in MySQL 5.7を参照してください。その説明では、アプリケーションが MySQL 5.7 での SQL モードの変更によって影響されるかどうかを評価するためのガイドラインが示されます。

  • MySQL 5.6 における暗黙の GROUP BY ソートへの依存は、非推奨になっています。グループ化された結果の特定のソート順序を実現するには、明示的な ORDER BY 句を使用することをお勧めします。GROUP BY ソートは、たとえば、オプティマイザがもっとも効率的であると考えるどのような方法でも、グループ化を指示できるようにしたり、ソートオーバーヘッドを回避したりするためなどに、今後のリリースで変更される可能性のある MySQL 拡張機能です。

  • 4.1 以前のパスワードと mysql_old_password 認証プラグイン。MySQL 4.1 より前で使用される古いハッシュ形式で格納されているパスワードは、ネイティブのパスワードハッシュ方式を使用するパスワードよりもセキュアでないため、使用しないようにしてください。4.1 以前のパスワードと mysql_old_password 認証プラグインが非推奨になりました。4.1 より前のパスワードハッシュを持つアカウントを使用して接続することを防ぐために、secure_auth システム変数はデフォルトで有効になりました。(このようなパスワードハッシュを持つアカウントに対して接続を許可するには、--secure_auth=0 を使用してサーバーを起動してください。ただし、4.1 以前のパスワードは非推奨であるため、secure_auth を無効にすることも非推奨です。)

    データベース管理者は、mysql_old_password 認証プラグインを使用するアカウントを、代わりに mysql_native_password を使用するように変換することが推奨されます。アカウントのアップグレード手順については、セクション6.3.8.3「4.1 よりも前のパスワードハッシュ方式と mysql_old_password プラグインからの移行」を参照してください。

    OLD_PASSWORD() 関数は 4.1 以前のパスワードハッシュを生成しますが、これは、old_passwords システム変数が 1 に設定されている場合に PASSWORD() が行う処理と同じです。OLD_PASSWORD() と old_passwords=1 は非推奨になっています。

  • --skip-innodb オプションとそのシノニム (--innodb=OFF、--disable-innodb など)。

  • date_format、datetime_format、および time_format システム変数 (これらは使用されていません)。

  • have_profiling、profiling、および profiling_history_size システム変数。

  • innodb_use_sys_malloc および innodb_additional_mem_pool_size システム変数。

  • timed_mutexes システム変数。これは何も行わず、何の効果もありません。

  • --language オプション。代わりに --lc-messages-dir オプションと --lc-messages オプションを使用してください。

  • ALTER TABLE の IGNORE 句。ALTER IGNORE TABLE は、レプリケーションの問題を引き起こし、一意のインデックスの作成用のオンライン ALTER TABLE を妨げ、外部キーの問題 (親テーブルで削除された行) を引き起こします。

  • msql2mysql、mysql_convert_table_format、mysql_find_rows、mysql_fix_extensions、mysql_setpermission、mysql_waitpid、mysql_zap、mysqlaccess、および mysqlbug ユーティリティー。

  • mysqlhotcopy ユーティリティー。代替方法には、mysqldump と MySQL Enterprise Backup があります。

削除された機能

次の項目は廃止され、MySQL 5.6 で削除されました。ほかのオプションがあれば、それを利用するためにアプリケーションを更新する必要があります。

  • --log サーバーオプションと log システム変数。代わりに、一般クエリーログを有効にするには --general_log オプションを使用し、一般クエリーログファイル名を設定するには --general_log_file=file_name オプションを使用してください。

  • --log-slow-queries サーバーオプションと log_slow_queries システム変数。代わりに、スロークエリーログを有効にするには --slow_query_log オプションを使用し、スロークエリーログファイル名を設定するには --slow_query_log_file=file_name オプションを使用してください。

  • --one-thread サーバーオプション。代わりに --thread_handling=no-threads を使用してください。

  • --safe-mode サーバーオプション。

  • --skip-thread-priority サーバーオプション。

  • --table-cache サーバーオプション。代わりに table_open_cache システム変数を使用してください。

  • --init-rpl-role オプションと --rpl-recovery-rank オプション、rpl_recovery_rank システム変数、および Rpl_status ステータス変数。

  • engine_condition_pushdown システム変数。optimizer_switch 変数の engine_condition_pushdown フラグを代わりに使用します。

  • have_csv、have_innodb、have_ndbcluster、および have_partitioning システム変数。代わりに SHOW PLUGINS を使用するか、INFORMATION_SCHEMA データベースの PLUGINS テーブルをクエリーします。

  • sql_big_tables システム変数。代わりに big_tables を使用してください。

  • sql_low_priority_updates システム変数。代わりに low_priority_updates を使用してください。

  • sql_max_join_size システム変数。代わりに max_join_size を使用してください。

  • max_long_data_size システム変数。代わりに max_allowed_packet を使用してください。

  • FLUSH MASTER および FLUSH SLAVE ステートメント。代わりに RESET MASTER および RESET SLAVE ステートメントを使用してください。

  • SLAVE START および SLAVE STOP ステートメント。START SLAVE および STOP SLAVE ステートメントを使用してください。

  • SHOW AUTHORS および SHOW CONTRIBUTORS ステートメント。

  • SET ステートメントの OPTION および ONE_SHOT 修飾子。

  • 値 DEFAULT をストアドプロシージャーまたはストアドファンクションのパラメータや、ストアドプログラムのローカル変数 (SET var_name = DEFAULT ステートメント) に割り当てることは、明示的に禁じられています。DEFAULT をシステム変数に割り当てることは、以前と同様に許可されています。

  • ほとんどの SHOW ENGINE INNODB MUTEX 出力は 5.6.14 で削除されます。SHOW ENGINE INNODB MUTEX 出力は、MySQL 5.7.2 で完全に削除されます。パフォーマンススキーマテーブル上にビューを作成することによって、比較可能な情報を生成できます。


PREV   HOME   UP   NEXT
Download this Manual
PDF (US Ltr) - 26.8Mb
PDF (A4) - 26.9Mb
HTML Download (TGZ) - 7.1Mb
HTML Download (Zip) - 7.2Mb
User Comments
User comments in this section are, as the name implies, provided by MySQL users. The MySQL documentation team is not responsible for, nor do they endorse, any of the information provided here.
Sign Up Login You must be logged in to post a comment.