このセクションでは、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 を呼び出すと、ランダムパスワードが MySQLroot
アカウントに割り当てられ、これらのアカウントに対して「有効期限切れパスワード」フラグが設定され、匿名ユーザー 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='
句をサポートするようになりました。この拡張機能は、サーバー環境により適切に適合する場所に file-per-table テーブルスペースを作成できる柔軟性をもたらします。たとえば、ビジーテーブルを SSD デバイス上に、または大きなテーブルを大容量 HDD デバイス上に配置できます。directory
'詳細は、セクション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 の開発」を参照してください。
-
レプリケーションとロギング 次のレプリケーション拡張機能が追加されました。
-
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_
ステータス変数は、特定のクライアント IP アドレスに適用されない接続エラーに関する情報を提供します。xxx
特定の 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
= DEFAULTDEFAULT
をシステム変数に割り当てることは、以前と同様に許可されています。ほとんどの
SHOW ENGINE INNODB MUTEX
出力は 5.6.14 で削除されます。SHOW ENGINE INNODB MUTEX
出力は、MySQL 5.7.2 で完全に削除されます。パフォーマンススキーマテーブル上にビューを作成することによって、比較可能な情報を生成できます。