Dear MySQL users,
MySQL Server 8.0.0-dmr (Milestone Release) is a new version of the world's
most popular open source database. This is the first public milestone
release of MySQL 8.0.
[Since this is the first announcement of MySQL 8.0, it is longer than
usual. Due to size limitations it is split in 3 parts. This is part 1.]
http://dev.mysql.com/doc/mysql-development-cycle/en/development-milestone-releases.html
As with any other pre-production release, caution should be taken when
installing on production level systems or systems with critical data.
Note that 8.0.0-dmr includes all features in MySQL 5.7.
For information on installing MySQL 8.0.0-dmr on new servers, please see
the MySQL installation documentation at
http://dev.mysql.com/doc/refman/8.0/en/installing.html
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
http://dev.mysql.com/downloads/mysql/
MySQL Server 8.0.0-dmr is also available from our repository for Linux
platforms, go here for details:
http://dev.mysql.com/downloads/repo/
Windows packages are available via the Installer for Windows:
http://dev.mysql.com/downloads/installer/
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.:
http://bugs.mysql.com/report.php
The following section lists the changes in MySQL 8.0.0-dmr since 5.7.
http://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8.0.0.html
Enjoy!
=============================================================================Changes in MySQL 8.0.0 (2016-09-12, Development Milestone Release)
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
* 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.
Compilation Notes
* 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.
Component Notes
* 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/.
Configuration Notes
* 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/).
Doxygen Notes
* 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.
Optimizer Notes
* 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).
Packaging Notes
* 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
Parser Notes
* 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;
[...continued...]
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/mysql