MySQL 5.7.6 がリリースされました


MySQL 5.7.6(マイルストーンリリース)は世界でもっともポピュラーなオープンソースデータベースの新しいバージョンです。これはMySQL 5.7の6番目のマイルストーンリリースです。


MySQL 5.7.6はMySQL 5.6のすべての機能を含んでいます

新しいサーバへMySQL 5.7.6をインストールする情報として、以下のMySQLのインストールドキュメントを参照してください。


MySQL Server 5.7.6は、ダウンロード・ページの開発リリースセクションから、ソースコードと多くのプラットフォームのためのバイナリをご利用いただけます。


MySQL 5.7.6で利用できるプラットフォームとパッケージのフォーマットはMySQL 5.6と同じです。


新規リリースされたMySQl 5.6.23と同様、5.7.6は完全なインストーラーの代替としてWebインストーラーも同梱されています



次の節では、開発開始から、そして5.6には含まれていないバグの修正、MySQL 5.7の変更を記載しています。これはオンラインでも閲覧できます。

Changes in MySQL 5.7.6 (2015-03-09, Milestone 16)


   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
       , and ALTER USER Syntax
       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
       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
       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

          + 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
            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.
            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

          + 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
       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

   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

   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
       For more information, see Initializing the Data Directory
       Using mysqld

   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
       References: See also Bug #20073366, Bug #59203, Bug

   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

          + 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
               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

          + 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
               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
            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
       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
       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

     * 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

          + 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

          + The exceptions are the geometry object construction
            functions, which remain unchanged: Point(),
            LineString(), Polygon(), MultiPoint(),
            MultiLineString(), MultiPolygon(), and

          + 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(),
            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_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

     * These changes have been made for spatial functions that
       operate on minimum bounding rectangles (MBRs) of geometry

          + 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()

          + 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."