オリジナル版：http://lists.mysql.com/announce/1136
2016年12月12日に、MySQL 5.7.17がリリースされました。同製品は、General Availability（GA版）となります。
Changes in MySQL 5.7.17 (主な変更点)
Compilation Notes（コンパイル関連）
* For GCC versions higher than 4.4,
-fno-expensive-optimizations was replaced with
-ffp-contract=off, which has the effect of enabling more
optimizations. Thanks to Alexey Kopytov for the patch.
(Bug #24571672, Bug #82760)
GCCのバージョン4.4以上では、-fno-expensive-optimizationsが-ffp-contract=offに置き換えられ、
より多くの機能を有効にする効果があります。
MySQL Enterprise Notes（MySQL Enterprise関連）
* Enterprise Encryption for MySQL Enterprise Edition now
enables server administrators to impose limits on maximum
key length by setting environment variables. These can be
used to prevent clients from using excessive CPU
resources by passing very long key lengths to
key-generation operations. For more information, see
Enterprise Encryption Usage and Examples
MySQL Enterprise Editionの「Enterprise Encryption」において、
サーバ管理者が環境変数設定によるキーの長さの上限値を設定できるようになりました。
これらは、キーが長いことが原因で、クライアントがキー生成のために
過度のCPUリソースを使ってしまうことを防ぎます。
詳細は下記のEnterprise暗号化の使用方法と例をご確認ください。
http://dev.mysql.com/doc/refman/5.7/en/enterprise-encryption-usage.html
(Bug #19687742)
Packaging Notes（パッケージ関連）
* RPM packages now are built with -DWITH_NUMA=ON for
platforms with NUMA support: OEL higher than EL5, Fedora,
SLES, Docker. (Bug #24689078)
PRMパッケージは、EL5以上のOEL、Fedora、SLES、DockerといったNUMAサポートの
プラットフォームに対して-DWITH_NUMA=ONでビルドされるようになりました。
Security Notes（セキュリティ関連）
* Incompatible Change: These changes were made to
mysqld_safe:
【非互換の変更】
以下の変更が、mysqld_safeに適用されています。
+ Unsafe use of rm and chown in mysqld_safe could result in privilege escalation.
chown now can be used only when the target directory is /var/log.
An incompatible change is that if the directory for the Unix socket file is missing,
it is no longer created; instead, an error occurs.
Due to these changes, /bin/bash is required to run mysqld_safe on Solaris.
/bin/sh is still used on other Unix/Linux platforms.
mysqld_safeでrmとchownコマンドを安全（適切）に使用しないと、
権限エスカレーションが発生してしまいます。
chownコマンドは/var/logディレクトリにのみ使用できます。
もしディレクトリにUnixソケットファイルがない場合、暗黙で作成されることなく
代わりにエラーが発生するようになり、この挙動が非互換となります。
これらの変更により、Solaris上でmysqld_safeを実行するためには/bin/bashが必要となります。
/bin/shは他のUnix/Linuxプラットフォーム上で引き続き使用されています。
+ The --ledir option now is accepted only on the command line, not in option files.
--ledirオプションはオプションファイルではなく、
コマンドラインでのみ使用できるようになりました。
+ mysqld_safe ignores the current working directory.
Other related changes:
mysqld_safeは作業中のカレントディレクトリを無視します。
その他の関連する変更点は下記となります。
+ Initialization scripts that invoke mysqld_safe pass --basedir explicitly.
mysqld_safeを起動する初期化スクリプトでは、明示的に--basedirを指定します。
+ Initialization scripts create the error log file
only if the base directory is /var/log or /var/lib.
初期化スクリプトは、ベースディレクトリが
/var/log か /var/lib である場合にのみ、エラーログファイルを作成します。
+ Unused systemd files for SLES were removed. (Bug #24483092, Bug #25088048)
References: See also: Bug #24464380, Bug #24388753.
SLES用の未使用のシステムファイルは削除されました。
* MySQL Server now includes a plugin library that enables
administrators to introduce an increasing delay in server
response to clients after a certain number of consecutive failed connection attempts.
This capability provides a deterrent
that slows down brute force attacks that attempt to access MySQL user accounts.
For more information, see The Connection-Control Plugin
http://dev.mysql.com/doc/refman/5.7/en/connection-control-plugin.html).
MySQLサーバに新しいプラグイン（ライブラリ）を追加されました。
そのプラグインにより、一定回数連続して接続に失敗した後に、
クライアントへのサーバ応答の遅延が拡大していることを管理者に知らせることができるようになりました。
この機能は、MySQLユーザアカウントにアクセスしようとするブルートフォース攻撃を
遅らせることのできる、抑止効果を持っています。
詳細は下記のConnection-Controlプラグインをご確認ください。
* OpenSSL is ending support for version 1.0.1 in December 2016; see
https://www.openssl.org/policies/releasestrat.html.
Consequently, MySQL Commercial Server builds now use version 1.0.2 rather than
version 1.0.1, and the linked OpenSSL library for the MySQL Commercial Server
has been updated from version 1.0.1 to version 1.0.2j.
For a description of issues fixed in this version, see
https://www.openssl.org/news/vulnerabilities.html.
This change does not affect the Oracle-produced MySQL Community build of MySQL Server,
which uses the yaSSL library instead.
OpenSSLは2016年12月を以ってバージョン 1.0.1のサポートを終了します。
その結果、MySQL Commercial Serverのビルドはバージョン1.0.1ではなく、バージョン1.0.2を使用し、
MySQL Commercial ServerのリンクされたOpenSSLライブラリは
バージョン1.0.1から1.0.2jにアップデートされています。
このバージョンの修正された問題については、下記を確認してください。
この変更は代わりにyaSSLライブラリに使用しているOracle-producedのMySQL
コミュニティサーバのビルドには影響しません。
Test Suite Notes（テストスイート関連）
* mysql-test-run.pl could not be run with --valgrind-option=--tool=custom_tool,
for values of custom_tool such as massif or helgrind,
because it added the options for memcheck that might not be understood by other tools.
Also, the mysql-test-run.pl --callgrind option did not work
because it supplied an invalid --base option to callgrind.
Thanks to Daniel Black for the patch on which the fixes were based.
(Bug #23713613, Bug#82039)
mysql-test-run.plは massif や helgrind のようなcustom_toolの値に対して
--valgrind-option=--tool=custom_toolで実行できませんでした。
なぜなら、他のツールでは理解できないかもしれないmemcheckのオプションを追加したからです。
また、mysql-test-run.plの--callgrindオプションは、
callgrindに無効な--baseオプションを指定したために、使用できませんでした。
Functionality Added or Changed（機能の追加、変更）
* Incompatible Change; Partitioning:
The generic partitioning handler in the MySQL server is deprecated,
and will be removed in MySQL 8.0. As part of this change,
the mysqld --partition and --skip-partition options as well as
the -DWITH_PARTITION_STORAGE_ENGINE build option
are also deprecated, and will later be removed;
partitioning will no longer be shown in the INFORMATION_SCHEMA.PLUGINS table or
in the output of SHOW PLUGINS.Following the removal of the generic partitioning handler,
the storage engine used for a given table will
be expected to provide its own ("native") partitioning
handler as the InnoDB and NDB storage engines currently do.
Currently, no other MySQL storage engines provide native partitioning support,
nor is any planned for any other storage engines
in current or development versions of MySQL.
Use of tables with nonnative partitioning now results in
an ER_WARN_DEPRECATED_SYNTAX warning.
Also, the server performs a check at startup to identify tables that use
nonnative partitioning; for any found, the server writes a message to its error log.
To disable this check, use the --disable-partition-engine-check option.
To prepare for migration to MySQL 8.0, any table with nonnative partitioning
should be changed to use an engine that provides native partitioning,
or be made nonpartitioned.
For example, to change a table to InnoDB,execute this statement:
ALTER TABLE table_name ENGINE = INNODB;
【非互換の変更】
パーティショニング：MySQLサーバの一般的なパーティショニングハンドラは非推奨でしたが、
MySQL 8.0では削除されます。
この変更点の一部として、mysqld --partitionと--skip-partitionオプションは
-DWITH_PARTITION_STORAGE_ENGINEビルドオプションと同様に廃止予定であり、
いずれは削除される予定です。パーティショニングはINFORMATION_SCHEMA.PLUGINSテーブル
もしくはSHOW PLUGINSの出力に表示されなくなります。
一般的なパーティショニングハンドラの削除後、特定のテーブルに使用されるストレージエンジンは、
InnoDBやNDBストレージエンジンが現在そうしているように、
それら独自のnativeなパーティショニングハンドラを提供することが期待されています。
現在、他のMySQLストレージエンジンは独自のパーティショニングサポートを提供していませんが、
MySQLの現在のもしくは開発バージョンにおける他のストレージエンジンでも計画自体されていません。
独自のものではないパーティショニングをテーブルに使用すると、
ER_WARN_DEPRECATED_SYNTAXの警告が発生します。
また、独自でないパーティショニングを使用したテーブルを特定するために
サーバが起動時にチェックを行います。
見つかった場合、サーバはエラーログにメッセージを書き込みます。
このチェックを無効にするためには、--disable-partition-engine-checkオプションを使用します。
MySQL 8.0の移行準備には、独自でないパーティショニングを持つテーブルは、
独自のパーティショニングを提供するエンジンを使用するように変更するか、
パーティショニングを使用しないべきです。
例えば、テーブルをInnoDBに変更するためには下記コマンドを実行します。
ALTER TABLE table_name ENGINE = INNODB;
* InnoDB: By default, InnoDB reads uncommitted data when calculating statistics.
In the case of an uncommitted transaction that deletes rows from a table,
InnoDB excludes records that are delete-marked
when calculating row estimates and index statistics,
which can lead to non-optimal execution plans for other transactions that
are operating on the table concurrently using a transaction isolation level
other than READ UNCOMMITTED.
To avoid this scenario, a new configuration option,
innodb_stats_include_delete_marked, can be enabled to ensure that
InnoDB includes delete-marked records
when calculating persistent optimizer statistics. (Bug #23333990)
InnoDB：デフォルトでは、統計情報を計算する際にInnoDBは未コミットのデータを読み込みます。
テーブルから行を削除する、未コミットのトランザクションが存在した場合、
InnoDBは行の見積もりとインデックス統計情報を計算する時に削除マークが付いているレコードを
除外します。これにより、READ UNCOMMITTED以外のトランザクション分離レベルを使用して、
テーブル上で同時に操作されている他のトランザクションが、最適でない実行計画となってしまいます。
このシナリオを避けるために、innodb_stats_include_delete_markedという
新しいオプション変数が使用できるようになりました。
この設定を有効にすると、永続的なオプティマイザ統計を計算しているときに
InnoDBが削除マークの付いたレコードも含むようになります。
* MySQL Group Replication is a new MySQL plugin that enables you
to create a highly available distributed
MySQL service across a group of MySQL server instances,
with data consistency, conflict detection and resolution,
and group membership services all built-in.
By using a powerful new group communication service, which provides
an implementation of the popular Paxos algorithm,
the group of MySQL Server instances automatically coordinates on data replication,
consistency, and membership. This provides all of the built-in mechanisms necessary for
making your MySQL databases highly available.
MySQLの「Group Replication」は新しいMySQLプラグインです。
これによりMySQLは、グループ（ノード）間でデータを共有することが可能となり
データの一貫性/競合の問題を解決しつつ、高い可用性を実現することが出来ます。
新たなグループコミュニケーション機能を使用することで、幅広く使用されている
Paxosアルゴリズムの実装が可能となり、MySQLサーバインスタンスのグループは
自動的にデータのレプリケーション、一貫性、そしてメンバーを調整できるようになります。
これは、MySQLデータベースの高可用性に必要なメカニズムを全て提供します。
By default Group Replication operates in single-primary mode
where a single server instance, called the primary, accepts write requests.
The remaining server instances in the group, called secondaries,
function as replicas of the primary.
In the event of an unexpected failure of the primary,
an automatic primary election process takes
place and one of the secondaries is elected as the new primary.
Group Replication also supports virtually synchronous multi-primary replication,
with certain considerations and restrictions, which offers update
everywhere functionality.
In this mode all members are equal and you can distribute your reads and writes across
all MySQL Server instances in the group.
Regardless of the operating mode, Group Replication
provides a dynamic membership service that relies on distributed failure detection.
Server instances can join and leave the group dynamically,
and you can query the group's membership list at any point
through Performance Schema tables.
Server instances that join the group automatically synchronize their state
with the group by doing an automatic point-in-time recovery which ensures
that they reach synchrony with the group.
Group Replicationは、デフォルトでは「single-primaryモード」として動作します。
これは、「プライマリ」と呼ばれる1台のサーバが書き込み要求を受け入れるモードです。
「セカンダリ」と呼ばれる、グループ内の他のサーバはプライマリのレプリカとして機能します。
予期せぬ障害がプライマリーに発生した際には、自動的にセカンダリのうちの一つが
新しいプライマリとして選ばれて、取って代わります。
また、Group Replicationはマルチマスタレプリケーション（複数サーバがプライマリ）も、
仮想的な同期となりますが、ある考慮事項と制限下でサポートしています
このモードでは、全メンバーが「プライマリ」となり、グループ内の全てのMySQLサーバで
読み書きを分散できるようになります。
また、動作モードに関わらず、Group Replicationは分散型システムの障害検知に効果的な
「動的メンバーシップ機能」を提供します。
MySQLサーバは動的にグループに参加したり、離脱することができ、Performance_Schema内の
テーブルを通して、いつでもグループのメンバー一覧を確認することができます。
グループに参加しているMySQLサーバは、確実にグループ内で同期が取れるよう、
自動的にポイントインタイムリカバリーを行うことで、データを同期します。
MySQL Group Replication's virtually synchronous replication
is also a fully integrated part of MySQL,
using the InnoDB storage engine, the Performance Schema tables,
standard GTIDs and the well known replication infrastructure
(binary and relay logs, multi-source replication, multi-threaded slave execution, etc.),
which makes it a familiar and intuitive experience for existing
MySQL users and makes it very easy to integrate
with MySQL's standard asynchronous and semisynchronous replication,
allowing you to mix and match as needed to create
varied and complex replication topologies.
Group Replicationの仮想的な同期レプリケーションは、InnoDBストレージエンジン、
Performance_Schema、標準的なGTIDやよく知られたレプリケーション（バイナリログや
リレーログ、マルチソースレプリケーション、マルチスレッドスレーブ等）を使っています。
そのため、既存のMySQLユーザが、使い慣れた直感的な操作やMySQLの標準的な非同期/同期
レプリケーションと簡単に統合できる一方で、必要な場合は多様で複雑なレプリケーション
トポロジーを作成し、混在し、一致できるようになります。
Bugs Fixed（バグ修正）
* Incompatible Change: A change made in MySQL 5.7.8 for handling of multibyte character
sets by LOAD DATA was reverted due to the replication incompatibility
(Bug #24487120, Bug #82641)References: See also: Bug #23080148.
【非互換の変更】
MySQL5.7.8で実施されたLOAD DATAのマルチバイト文字処理の変更が、
レプリケーションの非互換性を考慮して、元に戻りました。
* InnoDB: The INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
table reported NULL for a foreign key constraint name (UNIQUE_CONSTRAINT_NAME)
after restarting the server.(Bug #25126722)
InnoDB：INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTSテーブルが、サーバの再起動後、
外部キー制約名(UNIQUE_CONSTRAINT_NAME)をNULLとして報告していた問題を修正しました。
* InnoDB: After increasing the value of innodb_undo_logs and restarting the server,
the number of active undo tablespaces was not increased
when assigning undo tablespaces to newly allocated rollback segments. (Bug #24488141)
InnoDB：innodb_undo_logsの値を増やしてサーバを再起動した後、
新たに割り当てられたロールバックセグメントにundoテーブルスペースを割り当てると、
アクティブなundoテーブルスペースの数が増えなかった問題を修正しました。
* InnoDB: InnoDB incorrectly reported an error about
missing encryption when restoring pages from the doublewrite buffer during recovery.
(Bug #24471076)
InnoDB：InnoDBはリカバリ中にダブルライトバッファからページをリストアすると、
暗号化が失われたとの誤ったエラーを表示していた問題を修正しました。
* InnoDB: On a table without an explicitly defined primary key,
InnoDB did not replace the implicit clustered index
(GEN_CLUST_INDEX) when a unique key was defined on a NOT NULL column. (Bug #24397406)
InnoDB：明示的に定義されたプライマリーキーのないテーブルにおいて、InnoDBは
ユニークキーがNOT NULL制約を持つカラムの場合、クラスタインデックス(GEN_CLUST_INDEX)を
置き換えなかった問題を修正しました。
* InnoDB: A high priority transaction involving a foreign key constraint check
was not able to kill a lower priority blocking transaction. (Bug #24347476)
InnoDB：外部キー制約チェックを含む優先度の高いトランザクションが、
より優先度の低いブロッキングトランザクションをkillすることができていた問題を修正しました。
* InnoDB: InnoDB failed to free memory used by the full-text optimizer thread.
(Bug #24331265)
InnoDB：InnoDBがフルテキストオプティマイザスレッドによって使用される
メモリの開放に失敗していた問題を修正しました。
* InnoDB: When adding a new index, the server dropped an internally defined
foreign key index and attempted to use a secondary index defined on
a generated virtual column as the foreign key index, causing a server exit.
InnoDB now permits a foreign key constraint to reference a secondary index
defined on a generated virtual column. (Bug #23533396)
InnoDB：新しいインデックスを追加する時、サーバは内部的に定義された
外部キーインデックスを削除し、外部キーインデックスとして生成された仮想的なカラムで定義された
セカンダリインデックスを使用しようとし、サーバが落ちてしまっていました。
InnoDBは生成された仮想的なカラムで定義されたセカンダリインデックスを
外部キー制約が表示できるように修正されました。
* InnoDB: SHOW ENGINE INNODB STATUS output showed a "cleaning up" state for an idle thread.
Thread state information was not reset after statement execution.
(Bug #21974225, Bug #78777)
InnoDB：SHOW ENGINE INNODB STATUSの出力が、アイドル状態のスレッドに対して
cleaning upと表示されていました。スレッド状態情報が
クエリが実行された後にリセットされていなかった問題を修正しました。
* InnoDB: After a server restart, concurrent INSERT operations a table
with an auto-increment primary key resulted in a duplicate entry error.
The current auto-increment value was not changed after
auto_increment_increment and auto_increment_offset settings were modified.
(Bug #20989615, Bug #76872)
InnoDB：サーバを再起動した後、auto-incrementプライマリキーを持つテーブルで
同時にINSERT文を行うと、重複エントリーエラーが起こっていました。
auto_increment_incrementとauto_increment_offset設定が変更されていれば、
現在のauto-increment値は変更されません。
* Replication: When using XA transactions,
if a lock wait timeout or deadlock occurred for the applier (SQL) thread
on a replication slave, the automatic retry did not work.
The cause was that while the SQL thread would do a rollback,
it would not roll the XA transaction back.
This meant that when the transaction was retried, the first
event was XA START which was invalid as the XA transaction was already in progress,
leading to an XAER_RMFAIL error. (Bug #24764800)
References: See also: Bug #24923091, Bug #24966941.
レプリケーション：XAトランザクションを使用するとき、
スレーブ上のapplier(SQL)スレッドに対して、ロック待ちがタイムアウトやデッドロックを起こすと、
自動的なリトライは機能しませんでした。その原因はSQLスレッドがロールバックを行っている間、
XAトランザクションをロールバックしないことでした。
これは、トランザクションがリトライされたとき、
XAトランザクションが既に進んでいたために無効であったXA STARTという初めのイベントが、
XAER_RMFAILエラーとなっていた問題を修正しました。
* Replication: If the relay_log option was not specified in a configuration file,
the relay_log_basename variable was being internally constructed on the fly
using hostname but the relay_log_basename variable was not set.
When a slave tried to access this uninitialized variable it
resulted in an unexpected halt of the server. (Bug #24352667)
レプリケーション：もしrelay_logオプションが設定ファイル内で指定されていなかった場合、
relay_log_basename変数はホスト名を使って内部的に構築されていたが、
relay_log_basename変数が設定されていませんでした。
スレーブがこの初期化されていない変数にアクセスしようとすると、
サーバが予期せず停止してしまっていた問題を修正しました。
* Replication: Tables with special DEFAULT columns, such as DEFAULT CURRENT_TIMESTAMP,
that existed only on a slave were not being updated when using row-based replication
(binlog_format=ROW). (Bug #22916743)
DEFAULT CURRENT_TIMESTAMPのように特別なDEFAULTカラムを持つテーブルがある場合、
行ベースレプリケーションを使用しているとき(binlog_format=ROW)に、
スレーブのテーブルが更新されない問題を修正しました。
* Replication: Enabling semisynchronous replication when a
server was during the commit stage could cause the master to stop unexpectedly.
This was related to the patch for Bug# 75570. (Bug #22202516)
レプリケーション：準同期レプリケーションを有効にすると、
サーバがコミットの段階で予期せずマスターが停止してしまう問題を修正しました。
* Warnings occurring during CREATE TABLE ... SELECT could cause a server exit.
(Bug #24595992)
CREATE TABLE ... SELECTの実行するとWarningsが起きて、サーバが落ちてしまう問題を修正しました。
* Upgrading from MySQL 5.6 to 5.7.13 and then to 5.7.14
resulted in an incorrect column order in the mysql.slave_master_info system table.
(Bug #24384561, Bug #82384)
MySQL5.6から5.7.13へ、そして5.7.14へアップグレードする際、
mysql.slave_master_infoシステムテーブルでのカラムの順序が正しくなかった問題を修正しました。
* The optimizer could choose ref access on a secondary index
rather than range access on the primary key, even when the cost was higher.
(Bug #23259872, Bug #81341)
コストが高い場合でも、オプティマイザがプライマリーキーに対するrangeアクセスではなく、
セカンダリインデックスに対するrefアクセスを選択できていた問題を修正しました。
* For a query with ORDER BY and LIMIT, an optimizer trace did not record
the optimizer's switch to a different index. (Bug #23227428, Bug #81250)
ORDER BYやLIMITを使ったクエリの場合、オプティマイザトレースが異なるインデックスに
オプティマイザスイッチを記録していなかった問題を修正しました。
* For some deeply nested expressions, the optimizer failed to detect stack overflow,
resulting in a server exit.(Bug #23135667)
深くネストされた式の場合、オプティマイザがスタックオーバーフローの検知に失敗して
サーバが落ちてしまっていた問題を修正しました。
* A binary (in-place) upgrade from MySQL 5.6 to 5.7 followed by a data export performed
using mysqlpump resulted in an Invalid default value for date_column error
for attempts to reload the dump file. (Bug #22919028, Bug #80706)
MySQL5.6から5.7へバイナリ(in-place)をアップグレード後、
mysqlpumpを使用してデータのエクスポートを行うと、ダンプファイルをリロードしようとして
無効なデフォルト値（date_columnエラー）が発生する問題を修正しました。
* DROP INDEX operations could fail due to inconsistent handling of index prefix lengths
for TEXT-type columns(TINYTEXT and so forth). (Bug #22740093, Bug #80392)
TEXTタイプのカラムのインデックスプレフィックス長の一貫性のない処理により、
DROP INDEX処理が失敗していた問題を修正しました。
* The Performance Schema events_statements_summary_by_digest table could contain
multiple rows for the same statement digest and schema combination,
rather than the expected single (unique) row. (Bug #22320066, Bug #79533)
パフォーマンススキーマのevents_statements_summary_by_digestテーブルは
同じ文のダイジェストとスキーマの組み合わせに対して
単一（ユニーク）行ではなく、複数行を含んでいた問題を修正しました。
* An invalid string value in the WHERE clause of an UPDATE statement,
caused an index scan rather than a range scan to be used.
For values not present in the index, this could be much slower.
Now the optimizer determines this to be an "impossible WHERE" condition.
(Bug #21032418, Bug #76933)
UPDATE文のWHERE句で無効な文字列の値が指定されていると、
rangeスキャンよりもインデックススキャンが使用されていました。
インデックスに存在しない値の場合、これははるかに遅くなる可能性がありました。
今では、オプティマイザがimpossible WHERE条件であると判断します。
* An in-place ALTER TABLE operation failed to report an error
when adding a DATE or DATETIME column under these conditions:
a) the column was NOT NULL and no default value was supplied;
b) strict and NO_ZERO_DATE SQL modes were enabled;
c) the table was not empty.
An ALTER TABLE operation failed with an error rather than a warning
when adding a DATE or DATETIME column under these conditions:
a) the column was NOT NULL and no default value was supplied;
b) strict SQL mode was enabled and NO_ZERO_DATE SQL mode was not enabled;
c) the table was not empty. (Bug #16888677)
DATEやDATETIMEカラムを下記条件で追加すると、
ALTER TABLEの操作がエラーの報告に失敗してしまう問題を修正しました。
a)カラムにNOT NULL制約があり、デフォルト値が指定されていなかった場合
b)strictとNO_ZERO_DATEモードが有効であった場合
c)テーブルが空ではなかった場合
DATEやDATETIMEカラムを下記条件で追加すると、警告ではなくエラーで
ALTER TABLEの操作が失敗してしまう問題を修正しました。
a)カラムにNOT NULL制約があり、デフォルト値が指定されていなかった場合
b)strict SQLモードが有効で、NO_ZERO_DATE SQLモードが無効であった場合
c)テーブルが空ではなかった場合
上記以外にも、さまざまな変更やバグ修正が行われています。それらを全て確認する場合は、下記リリースノートを参照して下さい。
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html
MySQL5.7は、世界的に注目されているオープンソースデータベース「MySQL」の最新の開発バージョンです。MySQL5.6の後継バージョンにあたり、様々な機能や特徴があります。
- パフォーマンスやスケーラビリティの向上 - JSON形式のサポート - マルチソースレプリケーションの実装 - SYSスキーマの導入 - セキュリティの向上 - InnoDBにおけるGIS（位置データ）の対応
MySQL5.7には、上記以外にも様々な特徴があります。詳細については、下記URLを参照してください。
http://mysqlserverteam.com/whats-new-in-mysql-5-7-generally-available/
新たなサーバにMySQL5.7をインストール、または利用中のMySQLからMySQL5.7にアップグレードする際の情報については、以下を参照してください。
http://dev.mysql.com/doc/refman/5.7/en/installing.html
下記のダウンロードページから、MySQLのソースコード及び多数のプラットフォーム用バイナリが入手可能です。
http://dev.mysql.com/downloads/mysql/
その他、ご不明な点がございましたら、以下の公式リファレンスマニュアルをご利用いただけます。
http://dev.mysql.com/doc/refman/5.7/en/
以上