Rechercher dans le manuel MySQL
2.11.4 Changes in MySQL 8.0
Before upgrading to MySQL 8.0, review the changes described in this section to identify those that apply to your current MySQL installation and applications. Perform any recommended actions.
Changes marked as Incompatible change are incompatibilities with earlier versions of MySQL, and may require your attention before upgrading. Our aim is to avoid these changes, but occasionally they are necessary to correct problems that would be worse than an incompatibility between releases. If an upgrade issue applicable to your installation involves an incompatibility, follow the instructions given in the description.
Data Dictionary Changes
MySQL Server 8.0 incorporates a global data dictionary containing information about database objects in transactional tables. In previous MySQL series, dictionary data was stored in metadata files and nontransactional system tables. As a result, the upgrade procedure requires that you verify the upgrade readiness of your installation by checking specific prerequisites. For more information, see Section 2.11.5, “Preparing Your Installation for Upgrade”. A data dictionary-enabled server entails some general operational differences; see Section 14.7, “Data Dictionary Usage Differences”.
The caching_sha2_password
and
sha256_password
authentication plugins
provide more secure password encryption than the
mysql_native_password
plugin, and
caching_sha2_password
provides better
performance than sha256_password
. Due to
these superior security and performance characteristics of
caching_sha2_password
, it is as of MySQL 8.0
the preferred authentication plugin, and is also the default
authentication plugin rather than
mysql_native_password
. This change affects
both the server and the libmysqlclient
client
library:
For the server, the default value of the
default_authentication_plugin
system variable changes frommysql_native_password
tocaching_sha2_password
.This change applies only to new accounts created after installing or upgrading to MySQL 8.0 or higher. For accounts already existing in an upgraded installation, their authentication plugin remains unchanged. Existing users who wish to switch to
caching_sha2_password
can do so using theALTER USER
statement:The
libmysqlclient
library treatscaching_sha2_password
as the default authentication plugin rather thanmysql_native_password
.
The following sections discuss the implications of the more
prominent role of caching_sha2_password
:
caching_sha2_password Compatibility Issues and Solutions
If your MySQL installation must serve pre-8.0 clients and you
encounter compatibility issues after upgrading to MySQL 8.0 or
higher, the simplest way to address those issues and restore
pre-8.0 compatibility is to reconfigure the server to revert
to the previous default authentication plugin
(mysql_native_password
). For example, use
these lines in the server option file:
[mysqld]
default_authentication_plugin=mysql_native_password
That setting enables pre-8.0 clients to connect to 8.0 servers
until such time as the clients and connectors in use at your
installation are upgraded to know about
caching_sha2_password
. However, the setting
should be viewed as temporary, not as a long term or permanent
solution, because it causes new accounts created with the
setting in effect to forego the improved authentication
security provided by caching_sha2_password
.
The use of caching_sha2_password
offers more
secure password hashing than
mysql_native_password
(and consequent
improved client connection authentication). However, it also has
compatibility implications that may affect existing MySQL
installations:
Clients and connectors that have not been updated to know about
caching_sha2_password
may have trouble connecting to a MySQL 8.0 server configured withcaching_sha2_password
as the default authentication plugin, even to use accounts that do not authenticate withcaching_sha2_password
. This issue occurs because the server specifies the name of its default authentication plugin to clients. If a client or connector is based on a client/server protocol implementation that does not gracefully handle an unrecognized default authentication plugin, it may fail with an error such as one of these:Authentication plugin 'caching_sha2_password' is not supported
Authentication plugin 'caching_sha2_password' cannot be loaded: dlopen(/usr/local/mysql/lib/plugin/caching_sha2_password.so, 2): image not found
Warning: mysqli_connect(): The server requested authentication method unknown to the client [caching_sha2_password]
For information about writing connectors to gracefully handle requests from the server for unknown default authentication plugins, see Authentication Plugin Connector-Writing Considerations.
Clients that use an account that authenticates with
caching_sha2_password
must use either a secure connection (made using TCP using TLS/SSL credentials, a Unix socket file, or shared memory), or an unencrypted connection that supports password exchange using an RSA key pair. This security requirement does not apply tomysql_native_passsword
, so the switch tocaching_sha2_password
may require additional configuration (see Section 6.4.1.3, “Caching SHA-2 Pluggable Authentication”). However, client connections in MySQL 8.0 prefer use of TLS/SSL by default, so clients that already conform to that preference may need no additional configuration.Clients and connectors that have not been updated to know about
caching_sha2_password
cannot connect to accounts that authenticate withcaching_sha2_password
because they do not recognize this plugin as valid. (This is a particular instance of how client/server authentication plugin compatibility requirements apply, as discussed at Authentication Plugin Client/Server Compatibility.) To work around this issue, relink clients againstlibmysqlclient
from MySQL 8.0 or higher, or obtain an updated connector that recognizescaching_sha2_password
.Because
caching_sha2_password
is also now the default authentication plugin in thelibmysqlclient
client library, authentication requires an extra round trip in the client/server protocol for connections from MySQL 8.0 clients to accounts that usemysql_native_password
(the previous default authentication plugin), unless the client program is invoked with a--default-auth=mysql_native_password
option.
The libmysqlclient
client library for pre-8.0
MySQL versions is able to connect to MySQL 8.0 servers (except
for accounts that authenticate with
caching_sha2_password
). That means pre-8.0
clients based on libmysqlclient
should also
be able to connect. Examples:
Standard MySQL clients such as mysql and mysqladmin are
libmysqlclient
-based.The DBD::mysql driver for Perl DBI is
libmysqlclient
-based.MySQL Connector/Python has a C Extension module that is
libmysqlclient
-based. To use it, include theuse_pure=False
option at connect time.
When an existing MySQL 8.0 installation is upgraded to MySQL
8.0.4 or higher, some older
libmysqlclient
-based clients may
“automatically” upgrade if they are dynamically
linked, because they use the new client library installed by the
upgrade. For example, if the DBD::mysql driver for Perl DBI uses
dynamic linking, it can use the
libmysqlclient
in place after an upgrade to
MySQL 8.0.4 or higher, with this result:
Prior to the upgrade, DBI scripts that use DBD::mysql can connect to a MySQL 8.0 server, except for accounts that authenticate with
caching_sha2_password
.After the upgrade, the same scripts become able to use
caching_sha2_password
accounts as well.
However, the preceding results occur because
libmysqlclient
instances from MySQL 8.0
installations prior to 8.0.4 are binary compatible: They both
use a shared library major version number of 21. For clients
linked to libmysqlclient
from MySQL 5.7 or
older, they link to a shared library with a different version
number that is not binary compatible. In this case, the client
must be recompiled against libmysqlclient
from 8.0.4 or higher for full compatibility with MySQL 8.0
servers and caching_sha2_password
accounts.
MySQL Connector/J 5.1 through 8.0.8 is able to connect to MySQL 8.0 servers,
except for accounts that authenticate with
caching_sha2_password
. (Connector/J 8.0.9 or higher
is required to connect to
caching_sha2_password
accounts.)
Clients that use an implementation of the client/server protocol
other than libmysqlclient
may need to be
upgraded to a newer version that understands the new
authentication plugin. For example, in PHP, MySQL connectivity
usually is based on mysqlnd
, which currently
does not know about caching_sha2_password
.
Until an updated version of mysqlnd
is
available, the way to enable PHP clients to connect to MySQL 8.0
is to reconfigure the server to revert to
mysql_native_password
as the default
authentication plugin, as previously discussed.
If a client or connector supports an option to explicitly
specify a default authentication plugin, use it to name a plugin
other than caching_sha2_password
. Examples:
Some MySQL clients support a
--default-auth
option. (Standard MySQL clients such as mysql and mysqladmin support this option but can successfully connect to 8.0 servers without it. However, other clients may support a similar option. If so, it is worth trying it.)Programs that use the
libmysqlclient
C API can call themysql_options()
function with theMYSQL_DEFAULT_AUTH
option.MySQL Connector/Python scripts that use the native Python implementation of the client/server protocol can specify the
auth_plugin
connection option. (Alternatively, use the Connector/Python C Extension, which is able to connect to MySQL 8.0 servers without the need forauth_plugin
.)
caching_sha2_password-Compatible Clients and Connectors
If a client or connector is available that has been updated to
know about caching_sha2_password
, using it is
the best way to ensure compatibility when connecting to a MySQL
8.0 server configured with
caching_sha2_password
as the default
authentication plugin.
These clients and connectors have been upgraded to support
caching_sha2_password
:
The
libmysqlclient
client library in MySQL 8.0 (8.0.4 or higher). Standard MySQL clients such as mysql and mysqladmin arelibmysqlclient
-based, so they are compatible as well.The
libmysqlclient
client library in MySQL 5.7 (5.7.23 or higher). Standard MySQL clients such as mysql and mysqladmin arelibmysqlclient
-based, so they are compatible as well.MySQL Connector/C++ 1.1.11 or higher or 8.0.7 or higher.
MySQL Connector/J 8.0.9 or higher.
MySQL Connector/NET 8.0.10 or higher (through the classic MySQL protocol).
MySQL Connector/Node.js 8.0.9 or higher.
PHP: the X DevAPI PHP extension (mysql_xdevapi) supports
caching_sha2_password
.PHP: the PDO_MySQL and ext/mysqli extensions do not support
caching_sha2_password
. In addition, when used with PHP versions before 7.1.16 and PHP 7.2 before 7.2.4, they fail to connect withdefault_authentication_plugin=caching_sha2_password
even ifcaching_sha2_password
is not used.
caching_sha2_password and the root Administrative Account
For upgrades to MySQL 8.0, the authentication plugin existing
accounts remains unchanged, including the plugin for the
'root'@'localhost'
administrative account.
For new MySQL 8.0 installations, when you initialize the data
directory (using the instructions at
Section 2.10.1, “Initializing the Data Directory”), the
'root'@'localhost'
account is created, and
that account uses caching_sha2_password
by
default. To connect to the server following data directory
initialization, you must therefore use a client or connector
that supports caching_sha2_password
. If you
can do this but prefer that the root
account
use mysql_native_password
after installation,
install MySQL and initialize the data directory as you normally
would. Then connect to the server as root
and
use ALTER USER
as follows to
change the account authentication plugin and password:
If the client or connector that you use does not yet support
caching_sha2_password
, you can use a modified
data directory-initialization procedure that associates the
root
account with
mysql_native_password
as soon as the account
is created. To do so, use either of these techniques:
Supply a
--default-authentication-plugin=mysql_native_password
option along with--initialize
or--initialize-insecure
.Set
default_authentication_plugin
tomysql_native_password
in an option file, and name that option file using a--defaults-file
option along with--initialize
or--initialize-insecure
. (In this case, if you continue to use that option file for subsequent server startups, new accounts will be created withmysql_native_password
rather thancaching_sha2_password
unless you remove thedefault_authentication_plugin
setting from the option file.)
caching_sha2_password and Replication
In replication scenarios for which all servers have been
upgraded to MySQL 8.0.4 or higher, slave/replica connections to
master/primary servers can use accounts that authenticate with
caching_sha2_password
. For such connections,
the same requirement applies as for other clients that use
accounts that authenticate with
caching_sha2_password
: Use a secure
connection or RSA-based password exchange.
To connect to a caching_sha2_password
account
for master/slave replication:
Use any of the following
CHANGE MASTER TO
options:- MASTER_SSL = 1
- GET_MASTER_PUBLIC_KEY = 1
- MASTER_PUBLIC_KEY_PATH='path to RSA public key file'
Alternatively, you can use the RSA public key-related options if the required keys are supplied at server startup.
To connect to a caching_sha2_password
account
for Group Replication:
For MySQL built using OpenSSL, set any of the following system variables:
Alternatively, you can use the RSA public key-related options if the required keys are supplied at server startup.
Incompatible change: A MySQL storage engine is now responsible for providing its own partitioning handler, and the MySQL server no longer provides generic partitioning support.
InnoDB
andNDB
are the only storage engines that provide a native partitioning handler that is supported in MySQL 8.0. A partitioned table using any other storage engine must be altered—either to convert it toInnoDB
orNDB
, or to remove its partitioning—before upgrading the server, else it cannot be used afterwards.For information about converting
MyISAM
tables toInnoDB
, see Section 15.6.1.3, “Converting Tables from MyISAM to InnoDB”.A table creation statement that would result in a partitioned table using a storage engine without such support fails with an error (ER_CHECK_NOT_IMPLEMENTED) in MySQL 8.0. If you import databases from a dump file created in MySQL 5.7 (or earlier) using mysqldump into a MySQL 8.0 server, you must make sure that any statements creating partitioned tables do not also specify an unsupported storage engine, either by removing any references to partitioning, or by specifying the storage engine as
InnoDB
or allowing it to be set asInnoDB
by default.NoteThe procedure given at Section 2.11.5, “Preparing Your Installation for Upgrade”, describes how to identify partitioned tables that must be altered before upgrading to MySQL 8.0.
See Section 23.6.2, “Partitioning Limitations Relating to Storage Engines”, for further information.
Incompatible change: Several server error codes are not used and have been removed (for a list, see Features Removed in MySQL 8.0). Applications that test specifically for any of them should be updated.
Important change: The default character set has changed from
latin1
toutf8mb4
. These system variables are affected:The default value of the
character_set_server
andcharacter_set_database
system variables has changed fromlatin1
toutf8mb4
.The default value of the
collation_server
andcollation_database
system variables has changed fromlatin1_swedish_ci
toutf8mb4_0900_ai_ci
.
As a result, the default character set and collation for new objects differ from previously unless an explicit character set and collation are specified. This includes databases and objects within them, such as tables, views, and stored programs. Assuming that the previous defaults were used, one way to preserve them is to start the server with these lines in the
my.cnf
file:[mysqld] character_set_server=latin1 collation_server=latin1_swedish_ci
In a replicated setting, when upgrading from MySQL 5.7 to 8.0, it is advisable to change the default character set back to the character set used in MySQL 5.7 before upgrading. After the upgrade is completed, the default character set can be changed to
utf8mb4
.Incompatible change: As of MySQL 8.0.11, it is prohibited to start the server with a
lower_case_table_names
setting that is different from the setting used when the server was initialized. The restriction is necessary because collations used by various data dictionary table fields are based on thelower_case_table_names
setting that was defined when the server was initialized, and restarting the server with a different setting would introduce inconsistencies with respect to how identifiers are ordered and compared.
In MySQL 8.0.11, several deprecated features related to account management have been removed, such as use of the
GRANT
statement to modify nonprivilege characteristics of user accounts, theNO_AUTO_CREATE_USER
SQL mode, thePASSWORD()
function, and theold_passwords
system variable.Replication from MySQL 5.7 to 8.0 of statements that refer to these removed features can cause replication failure. Applications that use any of the removed features should be revised to avoid them and use alternatives when possible, as described in Features Removed in MySQL 8.0.
To avoid a startup failure on MySQL 8.0, remove any instance of
NO_AUTO_CREATE_USER
fromsql_mode
system variable settings in MySQL option files.Loading a dump file that includes the
NO_AUTO_CREATE_USER
SQL mode in stored program definitions into a MySQL 8.0 server causes a failure. As of MySQL 5.7.24 and MySQL 8.0.13, mysqldump removesNO_AUTO_CREATE_USER
from stored program definitions. Dump files created with an earlier version ofmysqldump
must be modified manually to remove instances ofNO_AUTO_CREATE_USER
.In MySQL 8.0.11, these deprecated compatibility SQL modes were removed:
DB2
,MAXDB
,MSSQL
,MYSQL323
,MYSQL40
,ORACLE
,POSTGRESQL
,NO_FIELD_OPTIONS
,NO_KEY_OPTIONS
,NO_TABLE_OPTIONS
. They can no longer be assigned to thesql_mode
system variable or used as permitted values for the mysqldump--compatible
option.Removal of
MAXDB
means that theTIMESTAMP
data type forCREATE TABLE
orALTER TABLE
is no longer treated asDATETIME
.Replication from MySQL 5.7 to 8.0 of statements that refer to the removed SQL modes can cause replication failure. This includes replication of
CREATE
statements for stored programs (stored procedures and functions, triggers, and events) that are executed while the currentsql_mode
value includes any of the removed modes. Applications that use any of the removed modes should be revised to avoid them.As of MySQL 8.0.3, spatial data types permit an
SRID
attribute, to explicitly indicate the spatial reference system (SRS) for values stored in the column. See Section 11.5.1, “Spatial Data Types”.A spatial column with an explicit
SRID
attribute is SRID-restricted: The column takes only values with that ID, andSPATIAL
indexes on the column become subject to use by the optimizer. The optimizer ignoresSPATIAL
indexes on spatial columns with noSRID
attribute. See Section 8.3.3, “SPATIAL Index Optimization”. If you want the optimizer to considerSPATIAL
indexes on spatial columns that are not SRID-restricted, each such column should be modified:Verify that all values within the column have the same SRID. To determine the SRIDs contained in a geometry column
col_name
, use the following query:If the query returns more than one row, the column contains a mix of SRIDs. In that case, modify its contents so all values have the same SRID.
Redefine the column to have an explicit
SRID
attribute.Recreate the
SPATIAL
index.
Several spatial functions were removed in MySQL 8.0.0 due to a spatial function namespace change that implemented an
ST_
prefix for functions that perform an exact operation, or anMBR
prefix for functions that perform an operation based on minimum bounding rectangles. The use of removed spatial functions in generated column definitions could cause an upgrade failure. Before upgrading, run mysqlcheck --check-upgrade for removed spatial functions and replace any that you find with theirST_
orMBR
named replacements. For a list of removed spatial functions, refer to Features Removed in MySQL 8.0.The
BACKUP_ADMIN
privilege is automatically granted to users with theRELOAD
privilege when performing an in-place upgrade to MySQL 8.0.3 or higher.From MySQL 8.0.13, because of differences between row-based or mixed replication mode and statement-based replication mode in the way that temporary tables are handled, there are new restrictions on switching the binary logging format at runtime.
SET @@SESSION.binlog_format
cannot be used if the session has any open temporary tables.SET @@global.binlog_format
andSET @@persist.binlog_format
cannot be used if any replication channel has any open temporary tables.SET @@persist_only.binlog_format
is allowed if replication channels have open temporary tables, because unlikePERSIST
,PERSIST_ONLY
does not modify the runtime global system variable value.SET @@global.binlog_format
andSET @@persist.binlog_format
cannot be used if any replication channel applier is running. This is because the change only takes effect on a replication channel when its applier is restarted, at which time the replication channel might have open temporary tables. This behavior is more restrictive than before.SET @@persist_only.binlog_format
is allowed if any replication channel applier is running.
INFORMATION_SCHEMA
views based onInnoDB
system tables were replaced by internal system views on data dictionary tables. AffectedInnoDB
INFORMATION_SCHEMA
views were renamed:Table 2.15 Renamed InnoDB Information Schema Views
Old Name New Name INNODB_SYS_COLUMNS
INNODB_COLUMNS
INNODB_SYS_DATAFILES
INNODB_DATAFILES
INNODB_SYS_FIELDS
INNODB_FIELDS
INNODB_SYS_FOREIGN
INNODB_FOREIGN
INNODB_SYS_FOREIGN_COLS
INNODB_FOREIGN_COLS
INNODB_SYS_INDEXES
INNODB_INDEXES
INNODB_SYS_TABLES
INNODB_TABLES
INNODB_SYS_TABLESPACES
INNODB_TABLESPACES
INNODB_SYS_TABLESTATS
INNODB_TABLESTATS
INNODB_SYS_VIRTUAL
INNODB_VIRTUAL
After upgrading to MySQL 8.0.3 or higher, update any scripts that reference previous
InnoDB
INFORMATION_SCHEMA
view names.The zlib library version bundled with MySQL was raised from version 1.2.3 to version 1.2.11.
The zlib
compressBound()
function in zlib 1.2.11 returns a slightly higher estimate of the buffer size required to compress a given length of bytes than it did in zlib version 1.2.3. ThecompressBound()
function is called byInnoDB
functions that determine the maximum row size permitted when creating compressedInnoDB
tables or inserting rows into compressedInnoDB
tables. As a result,CREATE TABLE ... ROW_FORMAT=COMPRESSED
orINSERT
operations with row sizes very close to the maximum row size that were successful in earlier releases could now fail.If you have compressed
InnoDB
tables with large rows, it is recommended that you test compressed tableCREATE TABLE
statements on a MySQL 8.0 test instance prior to upgrading.With the introduction of the
--innodb-directories
feature, the location of file-per-table and general tablespace files created with an absolute path or in a location outside of the data directory should be added to theinnodb_directories
argument value. Otherwise,InnoDB
is not able to locate these files during recovery. To view tablespace file locations, query theINFORMATION_SCHEMA.FILES
table:Undo logs can no longer reside in the system tablespace. In MySQL 8.0, undo logs reside in two undo tablespaces by default. For more information, see Section 15.6.3.4, “Undo Tablespaces”.
When upgrading from MySQL 5.7 to MySQL 8.0, any undo tablespaces that exist in the MySQL 5.7 instance are removed and replaced by two new default undo tablespaces. Default undo tablespaces are created in the location defined by the
innodb_undo_directory
variable. If theinnodb_undo_directory
variable is undefined, undo tablespaces are created in the data directory. Upgrade from MySQL 5.7 to MySQL 8.0 requires a slow shutdown which ensures that undo tablespaces in the MySQL 5.7 instance are empty, permitting them to be removed safely.When upgrading to MySQL 8.0.14 or later from an earlier MySQL 8.0 release, undo tablespaces that exist in the pre-upgrade instance as a result of an
innodb_undo_tablespaces
setting greater than 2 are treated as user-defined undo tablespaces, which can be deactivated and dropped usingALTER UNDO TABLESPACE
andDROP UNDO TABLESPACE
syntax, respectively, after upgrading. Upgrade within the MySQL 8.0 release series may not always require a slow shutdown which means that existing undo tablespaces could contain undo logs. Therefore, existing undo tablespaces are not removed by the upgrade process.Incompatible change: As of MySQL 8.0.17, the
CREATE TABLESPACE ... ADD DATAFILE
clause does not permit circular directory references. For example, the circular directory reference (/../
) in the following statement is not permitted:An exception to the restriction exists on Linux, where a circular directory reference is permitted if the preceding directory is a symbolic link. For example, the data file path in the example above is permitted if
any_directory
is a symbolic link. (It is still permitted for data file paths to begin with '../
'.)To avoid upgrade issues, remove any circular directory references from tablespace data file paths before upgrading to MySQL 8.0.17 or higher. To inspect tablespace paths, query the
INFORMATION_SCHEMA.INNODB_DATAFILES
table.Due to a regression introduced in MySQL 8.0.14, in-place upgrade on a case sensitive file system from MySQL 5.7 or a MySQL 8.0 release prior to MySQL 8.0.14 to MySQL 8.0.16 failed for instances with partitioned tables and
lower_case_table_names=1
. The failure was caused by a case mismatch issue related to partitioned table file names. The fix that introduced the regression was reverted, which permits upgrades to MySQL 8.0.17 from MySQL 5.7 or MySQL 8.0 releases prior to MySQL 8.0.14 to function as normal. However, the regression is still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases.In-place upgrade on a case sensitive file system from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 fails with the following error when starting the server after upgrading binaries or packages to MySQL 8.0.17 if partitioned tables are present and
lower_case_table_names=1
:Upgrading from server version version_number with partitioned tables and lower_case_table_names == 1 on a case sensitive file system may cause issues, and is therefore prohibited. To upgrade anyway, restart the new server version with the command line option 'upgrade=FORCE'. When upgrade is completed, please execute 'RENAME TABLE part_table_name TO new_table_name; RENAME TABLE new_table_name TO part_table_name;' for each of the partitioned tables. Please see the documentation for further information.
If you encounter this error when upgrading to MySQL 8.0.17, perform the following workaround:
Restart the server with
--upgrade=force
to force the upgrade operation to proceed.Identify partitioned table file names with lowercase suffixes:
For each file identified, rename the associated table using a temporary name, then rename the table back to its original name.
Verify that there are no partitioned table file names with lowercase suffixes (an empty result set should be returned).
Run
ANALYZE TABLE
on each renamed table to update the optimizer statistics in themysql.innodb_index_stats
andmysql.innodb_table_stats
tables.
Because of the regression still present in the MySQL 8.0.14, 8.0.15, and 8.0.16 releases, importing partitioned tables from MySQL 8.0.14, 8.0.15, or 8.0.16 to MySQL 8.0.17 is not supported on case sensitive file systems where
lower_case_table_names=1
. Attempting to do so results in a “Tablespace is missing for table” error.
Incompatible change: As of MySQL 8.0.13, the deprecated
ASC
orDESC
qualifiers forGROUP BY
clauses have been removed. Queries that previously relied onGROUP BY
sorting may produce results that differ from previous MySQL versions. To produce a given sort order, provide anORDER BY
clause.Queries and stored program definitions from MySQL 8.0.12 or lower that use
ASC
orDESC
qualifiers forGROUP BY
clauses should be amended. Otherwise, upgrading to MySQL 8.0.13 or higher may fail, as may replicating to MySQL 8.0.13 or higher slave servers.Some keywords may be reserved in MySQL 8.0 that were not reserved in MySQL 5.7. See Section 9.3, “Keywords and Reserved Words”. This can cause words previously used as identifiers to become illegal. To fix affected statements, use identifier quoting. See Section 9.2, “Schema Object Names”.
After upgrading, it is recommended that you test optimizer hints specified in application code to ensure that the hints are still required to achieve the desired optimization strategy. Optimizer enhancements can sometimes render certain optimizer hints unnecessary. In some cases, an unnecessary optimizer hint may even be counterproductive.
Incompatible change: In MySQL 5.7, specifying a
FOREIGN KEY
definition for anInnoDB
table without aCONSTRAINT
clause, or specifying thesymbol
CONSTRAINT
keyword without asymbol
, causesInnoDB
to use a generated constraint name. That behavior changed in MySQL 8.0, withInnoDB
using theFOREIGN KEY
value instead of a generated name. Because constraint names must be unique per schema (database), the change caused errors due to foreign key index names that were not unique per schema. To avoid such errors, the new constraint naming behavior has been reverted in MySQL 8.0.16, andindex_name
InnoDB
once again uses a generated constraint name.For consistency with
InnoDB
,NDB
releases based on MySQL 8.0.16 or higher use a generated constraint name if theCONSTRAINT
clause is not specified, or thesymbol
CONSTRAINT
keyword is specified without asymbol
.NDB
releases based on MySQL 5.7 and earlier MySQL 8.0 releases used theFOREIGN KEY
value.index_name
The changes described above may introduce incompatibilities for applications that depend on the previous foreign key constraint naming behavior.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 26/06/2006 gemaakt, de laatste keer de 26/10/2018 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/mysql-rf-upgrading-from-previous-series.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Referenties
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.