MySQL Server 8.0.0-dmr is available in source and binary form for a number of platforms from the "Development Releases" selection of our download pages at
MySQL Server 8.0.0-dmr is also available from our repository for Linux platforms, go here for details:
Windows packages are available via the Installer for Windows:
along with .ZIP (no-install) packages for more advanced needs.
8.0.0-dmr also comes with a web installer as an alternative to the full installer.
The web installer doesn't come bundled with any actual products and instead relies on download-on-demand to fetch only the products you choose to install. This makes the initial download much smaller but increases install time as the individual products will need to be downloaded.
We welcome and appreciate your feedback, bug reports, bug fixes, patches, etc.:
The following section lists the changes in MySQL 8.0.0-dmr since 5.7.
=============================================================================Changes in MySQL 8.0.0 (2016-09-12, Development Milestone Release)
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
* C API Notes
* Character Set Support
* Compilation Notes
* Component Notes
* Configuration Notes
* Data Dictionary Notes
* Data Type Notes
* Doxygen Notes
* Optimizer Notes
* Packaging Notes
* Parser Notes
* Performance Schema Notes
* Security Notes
* Spatial Data Support
* Test Suite Notes
* Functionality Added or Changed
* Bugs Fixed
Account Management Notes
* MySQL now supports roles, which are named collections of privileges. Roles can be created and dropped. Roles can have privileges granted to and revoked from them. Roles can be granted to and revoked from user accounts. The active applicable roles for an account can be selected from among those granted to the account, and can be changed during sessions for that account. For more information, see Roles (http://dev.mysql.com/doc/refman/8.0/en/roles.html).
* The grant tables in the mysql system database are now InnoDB (transactional) tables. Previously, these were MyISAM (nontransactional) tables. This change applies to these tables: user, db, tables_priv, columns_priv, procs_priv, proxies_priv. The change of grant table storage engine underlies an accompanying change to the behavior of account-management statements. Previously, an account-management statement that named multiple users could succeed for some users and fail for others. Now, each statement is transactional and either succeeds for all named users or rolls back and has no effect if any error occurs. The statement is not written to the binary log unless it succeeds. This behavior applies to these statements: ALTER USER, CREATE ROLE, CREATE USER, DROP ROLE, DROP USER, GRANT, RENAME USER, REVOKE. (SET PASSWORD is not listed. It applies to at most one user and was effectively transactional already.) If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate these changes into the mysql system database. Note If MySQL is upgraded from an older version but the grant tables have not been upgraded from MyISAM to InnoDB, the server considers them read only and account-management statements produce an error. Due to the change of storage engine from MyISAM to InnoDB, SELECT without ORDER BY on grant tables can produce different row orders than previously. However, SELECT without ORDER BY is not guaranteed to produce any particular order, so this is not an incompatibility as such. Rather, it is an application design issue that must be addressed.
C API Notes
* The libmysqlclient shared library major version number is increased from 20 (used in MySQL 5.7) to 21 for MySQL 8.0. (Bug #77600, Bug #21363863)
Character Set Support
* The utf8mb4 Unicode character set has a new general collation named utf8mb4_0900_ai_ci. utf8mb4 also has several new language-specific collations with characteristics similar to utf8mb4_0900_ai_ci except that language-specific rules take precedence where applicable. The language-specific collations are indicated by ISO 639-1 language codes in the collation name, as shown in the following table. In two cases the language code has an additional item that denotes a variant (German phone book order, Traditional Spanish).
Table 1 utf8mb4 UCA 9.0.0 Collations
Language Collation Croatian utf8mb4_hr_0900_ai_ci Czech utf8mb4_cs_0900_ai_ci Danish utf8mb4_da_0900_ai_ci Esperanto utf8mb4_eo_0900_ai_ci Estonian utf8mb4_et_0900_ai_ci German phone book order utf8mb4_de_pb_0900_ai_ci Hungarian utf8mb4_hu_0900_ai_ci Icelandic utf8mb4_is_0900_ai_ci Latvian utf8mb4_lv_0900_ai_ci Lithuanian utf8mb4_lt_0900_ai_ci Polish utf8mb4_pl_0900_ai_ci Classical Latin utf8mb4_la_0900_ai_ci Romanian utf8mb4_ro_0900_ai_ci Slovak utf8mb4_sk_0900_ai_ci Slovenian utf8mb4_sl_0900_ai_ci Modern Spanish utf8mb4_es_0900_ai_ci Traditional Spanish utf8mb4_es_trad_0900_ai_ci Swedish utf8mb4_sv_0900_ai_ci Turkish utf8mb4_tr_0900_ai_ci Vietnamese utf8mb4_vi_0900_ai_ci
utf8mb4_0900_ai_ci also works as an accent insensitive, case insensitive collation for the languages in the following table.
Table 2 Languages for Which utf8mb4_0900_ai_ci is Suitable
Language Name Language Code German (dictionary order) de English en French fr Irish Gaelic ga Indonesian id Italian it Luxembourgian lb Malay ms Dutch nl Portuguese pt Swahili sw Zulu zu
utf8mb4_da_0900_ai_ci also works as an accent insensitive, case insensitive collation for the languages in the following table.
Table 3 Languages for Which utf8mb4_da_0900_ai_ci is Suitable
Language Name Language Code Norwegian no Norwegian Bokm?l nb Norwegian Nynorsk nn The nonlanguage-specific utf8mb4_0900_ai_ci and language-specific utf8mb4_LANG_0900_ai_ci Unicode collations each have these characteristics:
+ The collation is based on Unicode Collation Algorithm (UCA) 9.0.0 (_0900), is accent insensitive (_ai), and case insensitive (_ci).
+ The collation works for all characters in the range [U+0, U+10FFFF].
+ If the collation is not language specific, it sorts all characters, including supplemental characters, in default order (described following). If the collation is language specific, it sorts characters of the language correctly according to language-specific rules, and characters not in the language in default order.
+ By default, the collation sorts characters having a code point listed in the DUCET table (Default Unicode Collation Element Table) according to the weight value assigned in the table. The collation sorts characters not having a code point listed in the DUCET table using their implicit weight value, which is constructed according to the UCA.
+ Characters in contraction sequences are treated as separate characters.
* CMake support now permits linking with the GNU gold linker if it is available; specify the -DUSE_LD_GOLD=1 option. (Bug #23759968)
* For building MySQL on Windows, the toolchain now prefers 64-bit tools when possible (previously 32-bit). This speeds up linking and avoids issues related to limited address space with the 32-bit linker. (Bug #22900585)
* The WITH_EXTRA_CHARSETS CMake option has been removed. MySQL builds are configured with all character sets by default now. Users who want fewer character sets can edit cmake/character_sets.cmake directly and recompile the server. (Bug #80005, Bug #22552125)
* MySQL source code now permits and uses C++11 features. To enable a good level of C++11 support across all supported platforms, the following minimum compiler versions now apply:
+ GCC: 4.8 or higher
+ Clang: 3.4 or higher (Xcode 7 on OS X)
+ Solaris Studio: 12.4 or higher (Solaris client build only)
+ Visual Studio: 2015
+ CMake: On Windows, the required Visual Studio version results in a required CMake version of 3.2.3 or higher On Solaris, the stlport library is no longer used. This makes the SUNPRO_CXX_LIBRARY CMake option obsolete, so it has been removed.
* MySQL Server now includes a component-based infrastructure for improving server extensibility:
+ A component provides services that are available to the server and other components. (With respect to service use, the server is a component, equal to other components.) Components interact with each other only through the services they provide.
+ The INSTALL COMPONENT and UNINSTALL COMPONENT statements provide an SQL interface for component manipulation at runtime.
+ A loader service registers installed components in the mysql.component system table, and installs registered components during the startup sequence for subsequent server restarts. For general information about the component infrastructure and its SQL-level interface, see Server Components (http://dev.mysql.com/doc/refman/8.0/en/server-components.html). For information about the internal implementation of components, see http://dev.mysql.com/doc/dev/mysql-server/.
* Incompatible Change; InnoDB: Prior to MySQL 8.0, enabling innodb_read_only did not prevent table creation for storage engines other than InnoDB. As of MySQL 8.0, enabling innodb_read_only prevents table creation for all storage engines. Table creation operations modify data dictionary tables in the mysql system database, but those tables use the InnoDB storage engine and cannot be modified if innodb_read_only is enabled. (Bug #21611899)
* The hardcoded memory page size of 8KB for the memory-mapped transaction coordinator was too small for platforms such as ARM64 and PowerPC where the page size is much larger. The server now invokes a system call to get the page size of the current platform rather than using a hardcoded value. A consequence for the --log-tc-size option is that the minimum and default values are now 6 times the page size. Also, the value must be a multiple of the page size. Thanks to Alexey Kopytov for the patch. (Bug #23014086, Bug #80818)
* MySQL now supports a SET PERSIST variant of SET statement syntax for making configuration changes at runtime that also persist across server restarts. Like SET GLOBAL, SET PERSIST is permitted for any global system variable that is dynamic (settable at runtime). The statement changes the runtime variable value, but also writes the variable setting to an option file named mysqld-auto.cnf in the data directory. At startup, the server processes this file after all other option files. For more information, see SET Syntax for Variable Assignment (http://dev.mysql.com/doc/refman/8.0/en/set-variable.html). To make information available showing how each system variable was most recently set, the Performance Schema now includes a variables_info table that lists each system variable, and the source from which it got that value. See Performance Schema variables_info Table (http://dev.mysql.com/doc/refman/8.0/en/variables-info-table.html). If you upgrade to this MySQL release from an earlier version, you must run mysql_upgrade (and restart the server) to incorporate this change into the Performance Schema.
* The deprecated mysql_install_db program has been removed from MySQL distributions. Data directory initialization should be performed by invoking mysqld with the --initialize or --initialize-insecure option instead. In addition, the deprecated --bootstrap option for mysqld that was used by mysql_install_db has been removed, and the INSTALL_SCRIPTDIR CMake option that controlled the installation location for mysql_install_db has been removed. Version 1 test suite code previously was located in the mysql-test/lib/v1 directory of MySQL source distributions. This code used mysql_install_db and has been removed. The MYSQL_INSTALL_DB environment variable and a value of 1 for the MTR_VERSION environment variable are no longer supported.
Data Dictionary Notes
* Incompatible Change: MySQL Server now incorporates a global data dictionary containing information about database objects in transactional tables. In previous MySQL releases, dictionary data was stored in metadata files and nontransactional system tables. Important A data dictionary-enabled server entails some general operational differences; see Data Dictionary Usage Differences (http://dev.mysql.com/doc/refman/8.0/en/data-dictionary-usage-differences.html). Also, for upgrades to MySQL 8.0 from MySQL 5.7, the upgrade procedure differs somewhat from previous MySQL releases and requires that you verify the upgrade readiness of your installation by checking specific prerequisites. For more information, see Upgrading MySQL (http://dev.mysql.com/doc/refman/8.0/en/upgrading.html), particularly Verifying Upgrade Prerequisites for Your MySQL 5.7 Installation (http://dev.mysql.com/doc/refman/8.0/en/upgrading.html#upgrade-prerequisites). InnoDB continues to use its own data dictionary in the MySQL 8.0.0 release. The following list briefly describes the main implications of this change:
+ The .frm metadata files previously associated with base tables and views no longer exist. Metadata previously stored in .frm files is now stored in data dictionary tables. Similarly, trigger metadata previously stored in .TRG and .TRN files is stored in a data dictionary table and those files no longer exist.
+ With the removal of .frm files, the 64KB table definition size limit imposed by the .frm file structure is removed.
+ With the removal of .frm files, the INFORMATION_SCHEMA.TABLES VERSION field now reports a hardcoded value of 10, which is the last .frm file version used in MySQL 5.7.
+ A new dictionary object cache that serves the MySQL data dictionary stores previously accessed data dictionary objects in memory to enable object reuse and minimize disk I/O. An LRU-based eviction strategy is used to evict least recently used objects from memory. The cache comprises several partitions that store different object types. For more information, see Dictionary Object Cache (http://dev.mysql.com/doc/refman/8.0/en/data-dictionary-object-cache.html).
+ New internal data dictionary APIs enable the server, internal storage engines, and plugins to access and store data in the MySQL data dictionary. Internal data dictionary APIs are introduced for handling of schemas, tablespaces, tablespace files, tables, partitioned tables, table partition data, triggers, stored routines, events, table objects, views, character sets, and collations.
+ Data dictionary tables are invisible, but in most cases there are corresponding INFORMATION_SCHEMA tables that can be queried. Conceptually, the INFORMATION_SCHEMA provides a view through which MySQL exposes data dictionary metadata. INFORMATION_SCHEMA queries for database objects are now, in general, more efficient because they use information from data dictionary table rather than requiring directory or file scans under the data directory. A new system variable, information_schema_stats, controls whether to use column statistics cached in INFORMATION_SCHEMA tables or the latest statistics directly from storage engines.
+ The foreign_keys and foreign_key_column_usage tables now store foreign key information. The standard SQL way to obtain foreign key information is by using the INFORMATION_SCHEMA REFERENTIAL_CONSTRAINTS and KEY_COLUMN_USAGE tables; these tables are now implemented as views on the foreign_keys, foreign_key_column_usage, and other data dictionary tables. For some foreign key errors, the server now produces more appropriate and more informative error messages. Note Incompatibility: Previously, MySQL supported foreign key names longer than 64 characters. Foreign key names as stored in the foreign_keys and foreign_key_column_usage tables are a maximum of 64 characters, per the SQL standard, so longer foreign key names are no longer permitted.
+ Because the data dictionary provides information about database objects, the server no longer checks directory names in the data directory to find databases. Consequently, the --ignore-db-dir option and ignore_db_dirs system variable are extraneous and have been removed. Update system configurations and application programs accordingly.
+ System table changes: o Many system tables have been converted from MyISAM (nontransactional) tables to InnoDB (transactional) tables. For example, as discussed elsewhere in these release notes, the grant tables are now InnoDB tables. Other examples follow. o The func table that stores user-defined function information in the mysql system database now is an InnoDB (transactional) table. Previously, it was a MyISAM (nontransactional) table. In consequence of this change, CREATE FUNCTION and DROP FUNCTION statements cause an implicit commit, even when used for user-defined functions (see Statements That Cause an Implicit Commit (http://dev.mysql.com/doc/refman/8.0/en/implicit-commit.html)). Previously, they caused an implicit commit when used for stored functions, but not for user-defined functions. o Previously, information about stored routines and events was stored in the proc and event tables of the mysql system database. Those tables are no longer used. Instead, information about stored routines and events is stored in the routines, events, and parameters data dictionary tables in the mysql system database. The old tables used the MyISAM (nontransactional) storage engine. The new tables use the InnoDB (transactional) engine. Creating a stored routine that contained illegal characters previously produced a warning. This is now an error. o To permit access to system tables (for example, time zone or log tables) to be distinguished from access to nonsystem tables, the server uses the Locking system tables and Opening system tables thread states rather than the System lock and Opening tables thread states. See General Thread States (http://dev.mysql.com/doc/refman/8.0/en/general-thread-states.html).
+ InnoDB changes: o Persistent InnoDB tablespaces now include transactional storage for Serialized Dictionary Information (SDI), which is metadata in serialized form that describes objects such as tables, columns, and indexes. Along with the disappearance of .frm and trigger metadata files, mentioned previously, you might notice the appearance of .SDI files. These are serialized data information files. SDI transactional storage is reserved for an in-progress feature not yet fully implemented. o A new command-line utility, ibd2sdi, is used to extract serialized dictionary information (SDI) from persistent InnoDB tablespaces. SDI data is not present in persistent InnoDB tablespaces in this release. The ibd2sdi utility is reserved for future use. o InnoDB startup code was refactored to support MySQL initialization changes related to the MySQL data dictionary feature.
+ Upgrade and downgrade implications: o To upgrade to MySQL 8.0 from MySQL 5.7, you must perform the upgrade procedure described at Upgrading MySQL (http://dev.mysql.com/doc/refman/8.0/en/upgrading.html). o Downgrading from MySQL 8.0 to MySQL 5.7 is only supported using the logical downgrade method (a mysqldump downgrade). In-place downgrades are not supported. (Bug #80481, Bug #22811659)
Data Type Notes
* Bit functions and operators comprise BIT_COUNT(), BIT_AND(), BIT_OR(), BIT_XOR(), &, |, ^, ~, <<, and >>. Prior to MySQL 8.0, bit functions and operators required BIGINT (64-bit integer) arguments and returned BIGINT values. Non-BIGINT arguments were converted to BIGINT prior to performing the operation and truncation could occur. Now bit functions and operators permit binary string type arguments (BINARY, VARBINARY, and the BLOB types) and return a value of like type, which enables them to take arguments and produce return values larger than 64 bits. Permitting binary arguments to bit functions and operators makes it easier not only to manipulate larger values, but to perform operations on certain types of data, such as UUID and IPv6 values. An implication of this change in behavior is that bit operations on binary arguments might produce a different result in MySQL 8.0 than in 5.7. For more information about the change, including how to prepare in MySQL 5.7 for potential incompatibilities between MySQL 5.7 and 8.0, see Bit Functions and Operators (http://dev.mysql.com/doc/refman/5.7/en/bit-functions.html), in MySQL 5.7 Reference Manual (http://dev.mysql.com/doc/refman/5.7/en/).
* The MySQL source code has been updated to use Doxygen for the internal documentation. The generated content for this milestone is available at http://dev.mysql.com/doc/dev/mysql-server/8.0.0. This is a work in progress.
* InnoDB: The storage engine interface now enables the optimizer to provide information about the size of the record buffer to be used for scans that the optimizer estimates will read multiple rows. The buffer size can vary based on the size of the estimate. InnoDB uses this variable-size buffering capability to reduce the overhead of latching and B-tree navigation. Previously, InnoDB used a small, fixed-size buffer.
* The optimizer now supports table-level hints for specifying whether derived tables or views should be merged into the outer query block rather than materialized using an internal temporary table. Examples: SELECT /*+ MERGE(dt) */ * FROM (SELECT * FROM t1) AS dt; SELECT /*+ NO_MERGE(dt) */ * FROM (SELECT * FROM t1) AS dt;
For more information, see Optimizer Hints (http://dev.mysql.com/doc/refman/8.0/en/optimizer-hints.html). (Bug #79554, Bug #22328100)
* MySQL now supports invisible indexes. An invisible index is not used by the optimizer at all, but is otherwise maintained normally. Indexes are visible by default. Invisible indexes make it possible to test the effect of removing an index on query performance, without making a destructive change that must be undone should the index turn out to be required. This feature applies to InnoDB tables, for indexes other than primary keys. To control whether an index is invisible explicitly for a new index, use a VISIBLE or INVISIBLE keyword as part of the index definition for CREATE TABLE, CREATE INDEX, or ALTER TABLE. To alter the invisibility of an existing index, use a VISIBLE or INVISIBLE keyword with the ALTER TABLE ... ALTER INDEX operation. For more information, see Invisible Indexes (http://dev.mysql.com/doc/refman/8.0/en/invisible-indexes.html).
* The mysql system database now contains a column_stats table designed to store statistics about column values. For more information, see Optimizer Statistics (http://dev.mysql.com/doc/refman/8.0/en/optimizer-statistics.html).
* Development milestone releases in previous MySQL series were numbered using a suffix of -mN, to indicate development milestone N. In MySQL 8.0, development releases use the suffix -dmr. For example, this release of MySQL is numbered 8.0.0-dmr. (Bug #80408, Bug #22748154)
* As a consequence of the use of C++11 features described elsewhere in these release notes, the following packaging changes have been made:
+ Support for Red Hat Enterprise Linux 5 and Oracle Linux 5 RPMs has been dropped
+ Generic binary tarball builds have been moved to Red Hat Enterprise Linux 6
* The parser rules for CREATE TABLE were refactored to be context independent and improve maintainability and extendibility. Several user-visible effects resulted from this work:
+ For generated columns, including NOT NULL NULL resulted in a column that included the NOT NULL attribute, which differed from nongenerated columns. Such definitions now use the final attribute NULL, resulting in a nullable column (consistent with nongenerated columns).
+ CREATE TEMPORARY TABLE no longer permits multiple instances of TEMPORARY.
+ Previously, PARSE_GCOL_EXPR was a keyword and could not be used as a label in stored programs. It is no longer a keyword and can be used as a label.
+ Messages for some syntax errors are more precise with respect to the location of the error within the statement.
* The parser rules for SELECT and UNION were refactored to be more consistent (the same SELECT syntax applies uniformly in each such context) and reduce duplication. Several user-visible effects resulted from this work:
+ NATURAL JOIN permits an optional INNER keyword (NATURAL INNER JOIN), in compliance with standard SQL.
+ Right-deep joins without parentheses are permitted (for example, ... JOIN ... JOIN ... ON ... ON), in compliance with standard SQL.
+ The parser accepts parentheses around query expressions. For example, (SELECT ... UNION SELECT ...) is permitted.
+ The parser better conforms to the documented permitted placement of the SQL_CACHE and SQL_NO_CACHE query modifiers.
+ Left-hand nesting of unions, previously permitted only in subqueries, is now permitted in top-level statements. For example, this statement is now accepted as valid: (SELECT 1 UNION SELECT 1) UNION SELECT 1;
-- MySQL General Mailing List For list archives: http://lists.mysql.com/mysql To unsubscribe: http://lists.mysql.com/mysql
This site manages and broadcasts several email lists pertaining to Lasso Programming and technologies related and used by Lasso developers. Sign up today!