Mysql Complete Notes

0 views

Skip to first unread message

Thora Buckner

unread,

Aug 3, 2024, 4:29:54 PM8/3/24

to exracrassme

Each NDB Cluster 8.4 release is based on a mainline MySQL Server release and a particular version of the NDB storage engine, as shown in the version string returned by executing SELECT VERSION() in the mysql client, or by executing the ndb_mgm client SHOW or STATUS command; for more information, see MySQL NDB Cluster 8.4.

For general information about features added in NDB Cluster 8.4, see What is New in MySQL NDB Cluster 8.4. For a complete list of all bug fixes and feature changes in MySQL NDB Cluster, please refer to the changelog section for each individual NDB Cluster release.

For additional MySQL 8.4 documentation, see the MySQL 8.4 Reference Manual, which includes an overview of features added in MySQL 8.4 that are not specific to NDB Cluster (What Is New in MySQL 8.4 since MySQL 8.0), and discussion of upgrade issues that you may encounter for upgrades from MySQL 8.3 to MySQL 8.4 (Changes in MySQL 8.4). For a complete list of all bug fixes and feature changes made in MySQL 8.4 that are not specific to NDB, see MySQL 8.4 Release Notes.

Updates to these notes occur as new product features are added, so that everybody can follow the development process. If a recent version is listed here that you cannot find on the download page ( ), the version has not yet been released.

The documentation included in source and binary distributions may not be fully up to date with respect to release note entries because integration of the documentation occurs at release build time. For the most up-to-date release notes, please refer to the online documentation instead.

Each NDB Cluster 7.6 release is based on a mainline MySQL Server release and a particular version of the NDB storage engine, as shown in the version string returned by executing SELECT VERSION() in the mysql client, or by executing the ndb_mgm client SHOW or STATUS command; for more information, see MySQL NDB Cluster 7.5 and NDB Cluster 7.6.

For general information about features added in NDB Cluster 7.6, see What is New in NDB Cluster 7.6. For a complete list of all bug fixes and feature changes in MySQL NDB Cluster, please refer to the changelog section for each individual NDB Cluster release.

For additional MySQL 5.7 documentation, see the MySQL 5.7 Reference Manual, which includes an overview of features added in MySQL 5.7 that are not specific to NDB Cluster (What Is New in MySQL 5.7), and discussion of upgrade issues that you may encounter for upgrades from MySQL 5.6 to MySQL 5.7 (Changes in MySQL 5.7). For a complete list of all bug fixes and feature changes made in MySQL 5.7 that are not specific to NDB, see MySQL 5.7 Release Notes.

Incompatible Change: CONVERT(string USING charset) did not compute the correct maximum length for its return value, which should be the same as that calculated for CAST(string AS charset). This meant that some conversions of strings from BINARY to nonbinary character sets which should have been rejected as invalid returned values instead.

Prior to upgrading, applications that may rely on the previous CONVERT() behavior should be checked and updated as necessary. In particular, for indexes on generated columns using CONVERT() with invalid values, you should correct such values, drop the index, then re-create it before upgrading to this release. In some cases, it may be simpler to rebuild the table using ALTER TABLE table FORCE, rather than dropping and re-creating the index. See SQL Changes, for more information. (Bug #33199145)

The output from EXPLAIN FORMAT=TREE hex-encoded ranges for multi-valued indexes, even when the data type was not a binary one. In addition, ranges using string types were also printed with hex-encoded values, when they had a binary collation. The latter issue also affected regular indexes, but was more visible with multi-valued indexes, since these always use utf8mb4_0900_bin collation. Now, hex-encoding is used only for string types having a binary character set. Strings with non-binary character sets are now printed in EXPLAIN FORMAT=TREE output as plain text, with escaping for any special characters. (Bug #33343948)

Inserting a CHAR value such as '12:00:00' into a DATE, DATETIME, or TIMESTAMP column raised the wrong error. In the case of a DATE column, this error was similar to Data truncation: Incorrect date value: '2012-00-00' for column 'd' at row 1. This occurred for both the binary and text protocols.

A fix in MySQL 8.0.27 for a previous issue changed the resolved type of a boolean expression from signed INT to unsigned BIGINT in order to simplify type handling, but what appeared then as a harmless metadata change turned out to cause problems for some of the MySQL Connectors.

Support for the TLS v1.0 and TLS v1.1 connection protocols is removed as of MySQL 8.0.28. The protocols were deprecated from MySQL 8.0.26. For background, refer to the IETF memo Deprecating TLS v1.0 and TLSv 1.1. Make connections using the more-secure TLSv1.2 and TLSv1.3 protocols. TLSv1.3 requires that both the MySQL Server software and the client application were compiled with OpenSSL 1.1.1 or higher.

From MySQL 8.0.28, client programs, including MySQL Shell, that support a --tls-version option for specifying TLS protocols for connections to the MySQL server cannot make a TLS/SSL connection with the protocol set to TLSv1 or TLSv1.1. If a client attempts to connect using these protocols, for TCP connections, the connection fails, and an error is returned to the client. For socket connections, if --ssl-mode is set to REQUIRED, the connection fails, otherwise the connection is made but with TLS/SSL disabled.

The shortcuts ASCII for CHARACTER SET latin1 and UNICODE for CHARACTER SET ucs2 are now deprecated, and you should expect their removal in a future version of MySQL. Using either of these now raises a warning; use CHARACTER SET instead. (WL #13146)

As a previous convenience, the server automatically restarted the Event Scheduler as needed when the super_read_only system variable was disabled. Now this same convenience is applied independently when the read_only system variable is disabled. Prior to this update, disabling read_only could also disable super_read_only if needed, but because the code was separate, the Event Scheduler was not restarted. (Bug #33539082)

Due to the fact that, as implemented, MATCH() does not act as a function of its arguments, but rather as a function of the row ID of the current row in the underlying scan of the base table, a query using a rollup column as the argument to this function tended to perform poorly, and with unreliable results. This being the case, the use of a rollup column with MATCH() is no longer permitted whenever the following conditions are true:

Previous to implementing single preparation of prepared statements in MySQL 8.0.22, TIME values were returned in such cases; before this was done, values used as arguments and their types were used to determine the result type of certain temporal functions at resolution time, such as DATE_ADD(), DATE_SUB(), and ADDTIME(). Afterwards, user variable references and dynamic parameters are considered constant for the lifetime of one execution only, requiring that the return type be determined in another fashion, in this case from the function type. For example, the default resolved type for DATE_ADD() was deemed to be DATETIME if the first argument was a dynamic parameter, since DATETIME accomodates all temporal values and thus an implicit reprepare can be avoided.

The change just described represents a regression; the problem is better solved by deriving a more precise resolved data type, and performing a reprepare only if that does not match the actual value of the parameter. (Such functionality was already in use in the MySQL server for numeric parameters.) This solution is implemented by this fix.

We now parse string and numeric values when temporal values are expected. When a valid temporal value is found, the value is converted. This fix also improves determination of resolved data types for temporal functions.

If the first argument is a dynamic parameter, its resolved type is DATE if the second argument is an interval that contains some combination of YEAR, MONTH, or DAY values only; otherwise, its type is DATETIME.

In addition, for DATE_ADD() and DATE_SUB(), if the resolved type of the first argument is DATE, and a DATETIME value is provided, the statement is reprepared so that the function has the resolved type DATETIME. Behavior is unchanged when a TIME value is provided.

Previously, loadable functions and stored functions shared the same namespace and could not have the same name. A subsequent implementation change eliminated the reason to share the same namespace and permitted a stored function to be created with the same name as an existing loadable function. To invoke the stored function, it is necessary to qualify it with a schema name. The server now generates a warning if the stored function name collides with an existing loadable function name. (Bug #33301931)

The result length of the GROUP_CONCAT() function was wrong when the value of group_concat_max_len was increased. With a small group_concat_max_len value, the result was correct. This issue was caused by arithmetic overflow.

For a query, a range scan can be picked first and the optimizer decide that the same range scan can be used to skip ordering. In some cases, when the requested order is not the same as the index order, a reverse index scan is required. If the requested ordering is on the key part that is not already used by the range scan, we update the number of used key parts for the range scan to reflect the change. The issue occurred because the key part information was not also updated, and when it was necessary to access key part information based on the number of key parts used.