オリジナル版：http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-6.html
MySQL 5.7.6(マイルストーンリリース)は世界でもっともポピュラーなオープンソースデータベースの新しいバージョンです。これはMySQL 5.7の6番目のマイルストーンリリースです。
このリリースの新機能はベータ品質です。他のプロダクションリリース前と同様にプロダクションレベルのシステムやクリティカルなデータを持つシステムにインストールする場合には十分に注意すべきです。
MySQL 5.7.6はMySQL 5.6のすべての機能を含んでいます
新しいサーバへMySQL 5.7.6をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。
http://dev.mysql.com/doc/refman/5.7/en/installing.html
MySQL Server 5.7.6は、ダウンロード・ページの開発リリースセクションから、ソースコードと多くのプラットフォームのためのバイナリをご利用いただけます。
http://dev.mysql.com/downloads/
MySQL 5.7.6で利用できるプラットフォームとパッケージのフォーマットはMySQL 5.6と同じです。
WindowsパッケージはWindowsインストーラーのための新しいインストーラ、もしくはZIP(ノンインストール)パッケージが利用いただけます。以前のMSIパッケージはもう利用できず、ポイントアンドクリック設定ウィザードと全てのMySQL製品でWindows向けの統一インストーラが利用可能なことに注意してください：
http://dev.mysql.com/downloads/installer/
新規リリースされたMySQl 5.6.23と同様、5.7.6は完全なインストーラーの代替としてWebインストーラーも同梱されています
Webインストーラーは実際の製品すべてにバンドルされているわけではなく、インストールのために洗濯したダウンロードオンデマンドの製品を選択したときにのみ同梱されます。これは最初にダウンロードするサイズを小さくしますが、個々のプロダクトをダウンロードする必要があるため、インストール時間は長くなります。
私たちはフィードバック、バグレポート、バグ修正パッチ等を歓迎します
http://bugs.mysql.com/report.php
次の節では、開発開始から、そして5.6には含まれていないバグの修正、MySQL 5.7の変更を記載しています。これはオンラインでも閲覧できます。
http://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-1.html
Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)
Note
This is a milestone release, for use at your own risk.
Significant development changes take place in milestone
releases and you may encounter compatibility issues, such as
data format changes that require attention in addition to the
usual procedure of running mysql_upgrade. For example, you
may find it necessary to dump your data with mysqldump before
the upgrade and reload it afterward.
Account Management Notes
* Incompatible Change: The CREATE USER and ALTER USER
statements have gained user-management capabilities.
Together, they now can be used to fully establish or
modify authentication, SSL, and resource-limit
properties, as well as manage password expiration and
account locking and unlocking. For example, ALTER USER
can assign passwords, and it can modify the
authentication plugin for users with no need for direct
manipulation of the mysql.user table. For details, see
CREATE USER Syntax
(http://dev.mysql.com/doc/refman/5.7/en/create-user.html)
, and ALTER USER Syntax
(http://dev.mysql.com/doc/refman/5.7/en/alter-user.html).
Account locking control is a new feature that permits
administrators to completely disable an account from
being used to connect to the server. Account locking
state is recorded in the account_locked column of the
mysql.user table. See User Account Locking
(http://dev.mysql.com/doc/refman/5.7/en/account-locking.html).
A new statement, SHOW CREATE USER, shows the CREATE USER
statement that creates the named user. The accompanying
Com_show_create_user status variable indicates how many
times the statement has been executed.
A new system variable,
log_backward_compatible_user_definitions, if enabled,
causes the server to log CREATE USER, ALTER USER, and
GRANT statements in backward-compatible (pre-5.7.6)
fashion. Enabling this variable promotes compatibility
for cross-version replication.
The authentication_string column in the mysql.user table
now stores credential information for all accounts. The
Password column, previously used to store password hash
values for accounts authenticated with the
mysql_native_password and mysql_old_password plugins, is
removed.
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the
server) to incorporate the changes to the mysql database.
mysql_upgrade moves Password column values to the
authentication_string column and removes the Password
column. For nonupgraded installations that have no
account_locked column, the server treats all accounts as
unlocked, and attempts to lock or unlock and account
produce an error.
The preceding changes make the following features
obsolete. They are now deprecated and support for them
will be removed in a future MySQL release:
+ Using GRANT to create users. Instead, use CREATE
USER. Following this practice makes the
NO_AUTO_CREATE_USER SQL mode immaterial for GRANT
statements, so it too is deprecated.
+ Using GRANT to modify account properties other than
privilege assignments. This includes authentication,
SSL, and resource-limit properties. Instead,
establish such properties at account-creation time
with CREATE USER or modify them afterward with ALTER
USER.
+ IDENTIFIED BY PASSWORD 'hash_string' syntax for
CREATE USER and GRANT. Instead, use IDENTIFIED BY
auth_plugin AS 'hash_string' for CREATE USER and
ALTER USER, where the 'hash_string' value is in a
format compatible with the named plugin.
+ The SET PASSWORD statement and the PASSWORD()
function. Instead, use ALTER USER to change account
passwords, and avoid using PASSWORD() in any
context.
Warning
The changes in this release result in a semantic
incompatibility for one SET PASSWORD syntax:
SET PASSWORD ... = 'literal string';
Previously, SET PASSWORD interpreted the string as a
password hash value to be stored directly. Now, SET
PASSWORD interprets the string as a plaintext string
and hashes it appropriately for the account
authentication plugin before storing it.
Note
Any application that uses PASSWORD() to create hash
values (a practice that has been discouraged for
some time) should be modified to use a different
hash-generation method. For suggestions, see the
description of PASSWORD() in Encryption and
Compression Functions
(http://dev.mysql.com/doc/refman/5.7/en/encryption-functions.html).
+ The old_passwords system variable. Account
authentication plugins can no longer be left
unspecified in the mysql.user table, so any
statement that assigns a password from a plaintext
string can unambiguously determine the hashing
method to use on the string before storing it in the
mysql.user table. This renders old_passwords
superflous.
Note
It is a known bug in this release that the following SET
PASSWORD syntax produces an error:
SET PASSWORD ... = PASSWORD('auth_string');
That syntax was to be deprecated, not removed. It will be
restored in the next release, but generate a warning due
to its deprecated status. These alternatives are
available, the first of which is the preferred form:
ALTER USER ... IDENTIFIED BY 'auth_string';
SET PASSWORD ... = 'auth_string';
The change in mysql.user table structure has
compatibility implications for upgrading and downgrading:
+ You cannot use mysqldump to dump the user table from
a version of MySQL older than 5.7.6 and reload the
dump file into MySQL 5.7.6 or later. Instead,
perform a binary (in-place) upgrade to MySQL 5.7.6
or later and run mysql_upgrade to migrate the
Password column contents to the
authentication_string column.
+ Because the Password column is gone in 5.7.6 and up,
downgrading to a version older than 5.7.6 requires a
special procedure. See Downgrading to MySQL 5.6
(http://dev.mysql.com/doc/refman/5.7/en/downgrading-to-previous-series.html).
Generated Columns
* MySQL now supports the specification of generated columns
in CREATE TABLE and ALTER TABLE statements. Values of a
generated column are computed from an expression
specified at column creation time. Generated columns can
be virtual (computed "on the fly" when rows are read) or
stored (computed when rows are inserted or updated). The
INFORMATION_SCHEMA.COLUMNS table shows information about
generated columns.
Uses for generated columns include simplifing queries
when applications select from a table using a complex
expression, simulating functional indexes, or
substituting for views. For more information, see
Generated Columns
(http://dev.mysql.com/doc/refman/5.7/en/create-table.html#create-table-generated-columns).
Installation Notes
* Previously, for a new MySQL installation on Unix and
Unix-like systems, initialization of the data directory
(including the tables in the mysql system database) was
done using mysql_install_db. On Windows, MySQL
distributions included a data directory with prebuilt
tables in the mysql database.
mysql_install_db functionality now has been integrated
into the MySQL server, mysqld. To use this capability to
initialize a MySQL installation, if you previously
invoked mysql_install_db manually, invoke mysqld with the
--initialize or --initialize-insecure option, depending
on whether you want the server to generate a random
password for the initial 'root'@'localhost' account.
As a result of this change, mysql_install_db is
deprecated, as is the special --bootstrap option that
mysql_install_db passes to mysqld. These will be removed
in a future MySQL release. Also, the $HOME/.mysql_secret
file written by mysql_install_db is no longer needed. If
it is present on your system, you can remove it.
Initializing a MySQL installation using mysqld works on
all platforms, including Windows. In particular, it is
possible to initialize a Windows installation without the
set of prebuilt tables for the mysql database. (However,
it is unnecessary to do so for this release because
Windows distributions still include the pre-built
tables.)
For more information, see Initializing the Data Directory
Using mysqld
(http://dev.mysql.com/doc/refman/5.7/en/data-directory-initialization-mysqld.html).
Optimizer Notes
* The optimizer now minimizes differences in handling of
views and subqueries in the FROM clause. One effect of
this is that subqueries in the FROM clause, previously
always materialized to an internal temporary table, now
may be merged into the outer query. This can improve
performance. Avoiding materialization also can enable the
optimizer to push down conditions to the subquery and
produce a more efficient execution plan. For an example,
see Optimizing Subqueries with Subquery Materialization
(http://dev.mysql.com/doc/refman/5.7/en/subquery-optimization.html#subquery-materialization).
References: See also Bug #20073366, Bug #59203, Bug
#11766159.
Packaging Notes
* Packaging scripts such as those included in RPM or Debian
packages have been modified per the principle that files
installed from MySQL distributions should have the most
restrictive permissions possible. In the following
description, assume that the account used to administer
MySQL has owner (user) = mysql, group = mysql.
+ Installers that create the mysql account do so with
a shell of /bin/false to prevent direct login to the
account.
+ The data directory and its contents are owned by and
accessible only to owner/group mysql/mysql, with
permissions of 750 for directories, 755 for
executable files, 640 for other files.
+ Others files (including executables and libraries)
have owner/group of root/root, with these
permissions:
o Executables: 755
o Man pages, character set files, header files,
test suite files: 644
o Library files: Conventions appropriate for the
host system
Packaging scripts that perform the preceding actions for
installation also perform them for upgrades, with the
exceptions that if the mysql account exists, it is left
unchanged, and if the data directory exists, its
permissions and ownership are left unchanged.
Performance Schema Notes
* The Performance Schema now incorporates these changes:
+ Previously, the Performance Schema enabled
instrumentation for new foreground threads if there
was a row in the setup_actors table that matched the
thread user and host. Now, the setup_actors table
has an ENABLED column that indicates whether or not
to enable instrumentation for matching foreground
threads. This permits instrumentation for matching
threads to be disabled explicitly. For more
information, see Pre-Filtering by Thread
(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-pre-filtering.html#performance-schema-thread-filtering).
+ Two previously hardcoded limits on SQL statement
handling are now configurable:
o The maximum number of bytes from SQL statements
to display in the SQL_TEXT column of statement
event tables, such as
events_statements_current.
o The number of bytes used for computing
statement digests. Digests appear in the
DIGEST_TEXT and DIGEST columns of statement
event tables.
Previously, both values were fixed at 1024. It is
now possible to change them at server startup using
the performance_schema_max_sql_text_length and
max_digest_length system variables. (The name
max_digest_length does not begin with
performance_schema_ because statement digesting is
now done at the SQL level even if the Performance
Schema is disabled and is available to other aspects
of server operation that could benefit from it. For
example, query rewrite plugins now make use of
statement digests, even if the Performance Schema is
disabled.)
The defaults remain at 1024, but the values can be
reduced to use less memory or increased to permit
longer statements to be distinguished for display
and digesting purposes. Each variable has a range
from 0 to 1024 x 1024.
Any bytes in excess of
performance_schema_max_sql_text_length are discarded
and do not appear in the SQL_TEXT column. Statements
differing only after that many initial bytes are
indistinguishable in this column.
Any bytes in excess of max_digest_length during
digest computation do not factor into digest values.
Statements differing only after that many bytes of
parsed statement tokens produce the same digest and
are aggregated for digest statistics.
For applications that generate very long statements
that differ only at the end, the ability to change
max_digest_length variables enables computation of
digests that distinguish statements that previously
were aggregated to the same digest. Conversely,
administrators can devote less server memory to
digest storage by reducing the values of this
variable. Administrators should keep in mind that
larger values result in correspondingly increased
memory requirements, particularly for workloads that
involve large numbers of simultaneous sessions.
(max_digest_length bytes are allocated per session.)
For more information, see Performance Schema
Statement Digests
(http://dev.mysql.com/doc/refman/5.7/en/performance-schema-statement-digests.html).
If you upgrade to this release of MySQL from an earlier
version, you must run mysql_upgrade (and restart the
server) to incorporate these changes into the
performance_schema database.
Security Notes
* The secure_file_priv system variable is used to limit the
effect of data import and export operations. The
following changes have been made to how the server
handles this variable:
+ The server checks the value of secure_file_priv at
startup and writes a warning to the error log if the
value is insecure. The setting is considered
insecure if secure_file_priv has an empty value, or
the value is the data directory or a subdirectory of
it, or a directory that is accessible by all users.
If secure_file_priv is set to a nonexistent path,
the server writes an error message to the error log
and exits.
+ secure_file_priv can be set to NULL to disable all
import and export operations.
+ Previously, the secure_file_priv system variable was
empty by default. Now the default value is platform
specific and depends on the value of the
INSTALL_LAYOUT CMake option, as shown in the
following table.
INSTALL_LAYOUT Value Default secure_file_priv Value
STANDALONE, WIN empty
DEB, RPM, SLES, SVR4 /var/lib/mysql-files
Otherwise mysql-files under the CMAKE_INSTALL_PREFIX value
+ To specify the default secure_file_priv value
explicitly if you are building from source, use the
new INSTALL_SECURE_FILE_PRIVPATH CMake option.
References: See also Bug #18140348.
* MySQL Server from Community Edition distributions now
tries to deploy with SSL support enabled automatically if
no SSL options are specified explicitly and it finds any
of the ca.pem, server-cert.pem, and server-key.pem files
in the data directory. In this case, clients can use a
secure connection merely by specifying --ssl on the
command line.
To make it easier to produce the files required to
support secure connections (for both SSL and RSA), MySQL
distributions now include the mysql_ssl_rsa_setup
utility. This utiliy uses the openssl command, so its use
is contingent on having OpenSSL installed on your
machine. When invoked, mysql_ssl_rsa_setup checks the
data directory for SSL/RSA files and uses openssl to
create them if they are missing. For more information,
see mysql_ssl_rsa_setup --- Create SSL/RSA Files
(http://dev.mysql.com/doc/refman/5.7/en/mysql-ssl-rsa-setup.html).
If the server automatically uses SSL files at startup, it
writes a message to the error log. If the server finds
that the CA certificate is self-signed, it writes a
warning to the error log. (The certificate will be
self-signed if created by mysql_ssl_rsa_setup.)
Spatial Data Support
* Spatial functions now allocate memory in larger chunks to
reduce number of allocation calls and reduce overhead.
(Bug #20073459)
* A new set of spatial convenience functions is available:
+ ST_Distance_Sphere(): Returns the mimimum distance
between two geometries.
+ ST_IsValid(): Checks whether a geometry is valid.
+ ST_MakeEnvelope(): Returns the rectangle that forms
the envelope around two points.
+ ST_Simplify(): Returns a simplified geometry.
+ ST_Validate(): Returns a validated geometry, or NULL
if it is invalid.
For details, see Spatial Convenience Functions
(http://dev.mysql.com/doc/refman/5.7/en/spatial-convenience-functions.html).
* GIS code now uses Boost.Geometry.Rtree to improve
handling of geometry collection arguments in binary GIS
functions. The minimum bounding rectangles (MBRs) of
geometry collection components are used to set up an
rtree index, which is used to search for possible
matching components using each MBR of the components of
the other geometry collection. The results from the rtree
index search are provided to precise computation
algorithms to avoid unnecessary (and much more expensive)
precise computation. As a result, the time complexity of
handling geometry collection arguments in GIS algorithms
is reduced from O(N^2) to O(NlogN).
* Functions for checking spatial relations now use
functionality available in Boost.Geometry 1.56 and up:
ST_Contains(), ST_Crosses(), ST_Disjoint(), ST_Equals(),
ST_Intersects(), ST_Overlaps(), ST_Touches(),
ST_Within(). Specifically, these functions:
+ Now are able to test the relationship between all
pairs of argument types handled by Boost.Geometry.
+ Raise an exception for invalid argument types when
the previous implementation may not have.
This work also corrected issues that ST_Overlaps()
returned 1 and ST_Intersects() returned 0 for two
polygons that shared only a boundary, and that
ST_Intersects() sometimes incorrectly calculated the
result for intersections of LineString and Polygon.
References: See also Bug #68091, Bug #16174580, Bug
#71076, Bug #17894858.
* The spatial function namespace is being made more
consistent, with the ultimate goal that each spatial
function name begins with ST_ if it performs an exact
operation, or with MBR if it performs an operation based
on minimum bounding rectangles.
Currently, some functions have two implementations and up
to three related names: A name with an ST_ prefix, and a
name with an MBR prefix, and a name with no prefix:
+ The name with an ST_ prefix performs an exact
operation.
+ The name with an MBR prefix performs an operation
based on minimum bounding rectangles.
+ The name with neither prefix sometimes is an alias
for the ST_ name (as with Area() and ST_Area()),
sometimes an alias for the MBR name (as with
Contains() and MBRContains()),
This release implements the following changes in spatial
function naming:
+ A function with an ST_ prefix is added for each
non-MBR function that has no ST_ name.
+ Each function that does not begin with ST_ or MBR is
deprecated.
+ The exceptions are the geometry object construction
functions, which remain unchanged: Point(),
LineString(), Polygon(), MultiPoint(),
MultiLineString(), MultiPolygon(), and
GeometryCollection().
+ These functions are deprecated in favor of the MBR
names: Contains(), Disjoint(), Equals(),
Intersects(), Overlaps(), Within().
+ These functions are deprecated in favor of the ST_
names: Area(), AsBinary(), AsText(), AsWKB(),
AsWKT(), Buffer(), Centroid(), ConvexHull(),
Crosses(), Dimension(), Distance(), EndPoint(),
Envelope(), ExteriorRing(), GeomCollFromText(),
GeomCollFromWKB(), GeomFromText(), GeomFromWKB(),
GeometryCollectionFromText(),
GeometryCollectionFromWKB(), GeometryFromText(),
GeometryFromWKB(), GeometryN(), GeometryType(),
InteriorRingN(), IsClosed(), IsEmpty(), IsSimple(),
LineFromText(), LineFromWKB(), LineStringFromText(),
LineStringFromWKB(), MLineFromText(),
MLineFromWKB(), MPointFromText(), MPointFromWKB(),
MPolyFromText(), MPolyFromWKB(),
MultiLineStringFromText(), MultiLineStringFromWKB(),
MultiPointFromText(), MultiPointFromWKB(),
MultiPolygonFromText(), MultiPolygonFromWKB(),
NumGeometries(), NumInteriorRings(), NumPoints(),
PointFromText(), PointFromWKB(), PointN(),
PolyFromText(), PolyFromWKB(), PolygonFromText(),
PolygonFromWKB(), SRID(), StartPoint(), Touches(),
X(), Y().
+ These ST_ names are added and are preferred over the
corresponding non-ST_ names, which now are
deprecated: ST_GeomCollFromTxt(),
ST_MLineFromText(), ST_MLineFromWKB(),
ST_MPointFromText(), ST_MPointFromWKB(),
ST_MPolyFromText(), ST_MPolyFromWKB(),
ST_MultiLineStringFromText(),
ST_MultiLineStringFromWKB(),
ST_MultiPointFromText(), ST_MultiPointFromWKB(),
ST_MultiPolygonFromText(), ST_MultiPolygonFromWKB().
+ ST_Length() is added to implement the same operation
as the now-deprecated GLength(), which has a
nonstandard name because a function named Length()
already existed (to calculate string lengths).
Use of deprecated functions produces a warning. The
deprecated functions will be removed in a future MySQL
release.
* These changes have been made for spatial functions that
operate on minimum bounding rectangles (MBRs) of geometry
values:
+ Two new functions test the covering relationship of
two geometries using their MBRs. MBRCovers()
indicates whether the MBR of one geometry covers
that of another. MBRCoveredBy() tests the opposite,
indicating whether the MBR of one geometry is
covered by that of another.
+ The spatial function MBREquals() has been
implemented. It should be used in preference to
MBREqual(), which is now deprecated. (The new name
is more consistent with the similar Equals()
function.)
+ MBRTouches() now correctly uses the geometry MBRs,
not the geometries themselves.
+ MBRTouches() and MBRWithin() better conform to the
Open Geospatial Consortium specification: When a
point lies on the boundary of a line segment or
polygon, or when a line segment lies totally on the
boundary of a polygon, it is not considered "within"
but instead "touches." Also, two identical points
are not considered "touches."
これ以外にも多数の変更点がございます。
詳細は以下のページにてご確認ください。
http://lists.mysql.com/announce