8 Major MySQL 8.4 Changes That Every Team Should Review Before Migration

What’s new in MySQL 8.4 ?

At first glance, MySQL 8.4 may appear to be a routine incremental release. However, upon closer inspection, it introduces a number of important changes, many of which carry significant operational implications. From the deprecation of legacy authentication plugins to stricter privilege enforcement and the removal of long-standing administrative commands, this release includes updates that impact developers, database administrators, and application teams alike.

This article is not a simple changelog. Instead, it highlights the most critical behavioral changes, improvements, and compatibility considerations that should be reviewed carefully before adopting MySQL 8.4 in any production environment.

1 . Authentication Changes

One of the first and most impactful changes in MySQL 8.4 is the removal of the mysql_native_password authentication method. Earlier, MySQL supported both mysql_native_password and caching_sha2_password, giving flexibility for legacy compatibility.

From 8.4 onward, mysql_native_password is no longer available. Applications, replication configurations, and automated scripts that depend on this plugin must be updated. It is recommended to use caching_sha2_password, now the default and more secure sha256_password for environments requiring higher security.

Attempting to create a user with mysql_native_password will now result in an error:

mysql> create user jelson@'localhost' identified with mysql_native_password by 'SecurePa$$word';
ERROR 1524 (HY000): Plugin 'mysql_native_password' is not loaded

mysql> CREATE USER 'jelson'@'localhost' IDENTIFIED WITH caching_sha2_password BY 'SecurePa$$word'; 
Query OK, 0 rows affected (0.07 sec)

To ensure compatibility, all clients and connectors must support the newer authentication methods before proceeding with an upgrade.

2 . Replication Terminology Updates

MySQL has now fully transitioned to using SOURCE and REPLICA in place of the legacy MASTER and SLAVE terminology. 

This change is not merely cosmetic. Any existing scripts, monitoring solutions, or documentation using the older terms must be updated accordingly. This shift also reflects modern, inclusive terminology that aligns with broader industry standards.

mysql> stop replica;
Query OK, 0 rows affected (0.06 sec)

mysql> reset replica all;
Query OK, 0 rows affected (0.02 sec)

mysql> CHANGE REPLICATION SOURCE TO SOURCE_HOST = '172.17.0.3',SOURCE_PORT=3306, SOURCE_USER = 'repl', SOURCE_PASSWORD = 'replica@118', SOURCE_LOG_FILE = 'mysql-bin.000001', SOURCE_LOG_POS = 123;
Query OK, 0 rows affected (0.02 sec)

mysql> start replica;
Query OK, 0 rows affected (0.10 sec)

3 . AUTO_INCREMENT Changes

Developers relying on AUTO_INCREMENT with FLOAT or DOUBLE types will encounter errors in MySQL 8.4. This feature, deprecated in previous versions, has now been fully removed. 

If your schema still uses these types for auto-incrementing fields (which isn’t ideal anyway), now's the time to refactor. Stick with INT, BIGINT, or other integer-based types for any column that needs automatic value generation.

mysql> CREATE TABLE AutoInc_Float (
-> id FLOAT AUTO_INCREMENT PRIMARY KEY,
-> data VARCHAR(255)
-> );
ERROR 1063 (42000): Incorrect column specifier for column 'id'

This change improves consistency and prevents potential rounding issues that could have occurred with floating point auto-increments.

4 . Automatic Histogram Updates

A significant improvement in query optimization is the ability to auto-refresh histograms marked with AUTO UPDATE when running ANALYZE TABLE.

This behavior results in better execution plans and more accurate cardinality estimates without requiring manual histogram refreshes. The change is especially beneficial on large datasets where optimizer accuracy directly impacts performance.

mysql> ANALYZE TABLE orders UPDATE HISTOGRAM ON order_status WITH 10 BUCKETS AUTO UPDATE;
+---------------+-----------+----------+---------------------------------------------------------+
| Table         | Op        | Msg_type | Msg_text                                                |
+---------------+-----------+----------+---------------------------------------------------------+
| galaxy.orders | histogram | status   | Histogram statistics created for column 'order_status'. |
+---------------+-----------+----------+---------------------------------------------------------+

5 . New Privilege: FLUSH_PRIVILEGES

MySQL 8.4 introduces a dedicated FLUSH_PRIVILEGES privilege, offering more granular access control. Previously, users with broad administrative privileges could run this command by default.

With this update, explicit privileges are required to execute FLUSH PRIVILEGES. This change is especially useful in multi-tenant environments and scenarios requiring strict privilege management.

mysql> FLUSH PRIVILEGES;
ERROR 1227 (42000): Access denied; you need (at least one of) the RELOAD or FLUSH_PRIVILEGES privilege(s) for this operation

mysql> GRANT FLUSH_PRIVILEGES ON *.* TO `jelson`@`localhost`;
Query OK, 0 rows affected (0.01 sec)

mysql> show grants;
+-------------------------------------------------------+
| Grants for jelson@localhost                           |
+-------------------------------------------------------+
| GRANT USAGE ON *.* TO `jelson`@`localhost`            |
| GRANT FLUSH_PRIVILEGES ON *.* TO `jelson`@`localhost` |
+-------------------------------------------------------+

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.01 sec)

6 . InnoDB Default Adjustments

Several InnoDB system variables have new default values in MySQL 8.4. These changes aim to optimize performance and resource usage without requiring manual tuning.

These updated defaults improve performance and scalability for most workloads, while still allowing custom tuning for specific environments.

7 . mysqldump Enhancements

The mysqldump utility in MySQL 8.4 adds a new option --output-as-version, enabling version-aware exports. This allows compatibility with older versions during backups and migrations.

Two output versions are currently supported:

• BEFORE_8_2_0 :→ for versions from 8.0.23 through 8.1.0
• BEFORE_8_0_23 :→for versions prior to 8.0.23

[jelson@centos7 ~]$ mysqldump -ujelson -p --output-as-version=BEFORE_8_2_0 --events galaxy > event_bkp_8.2.sql

This is a lifesaver if you're preparing cross-version restores or backups for mixed-version clusters.

8 . FLUSH HOSTS Removed

The FLUSH HOSTS command has been removed in MySQL 8.4. Administrators must now use SQL-based alternatives via the performance_schema.

To clear the host cache, use:

mysql> flush hosts;
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'hosts' at line 1

mysql> TRUNCATE TABLE performance_schema.host_cache;
Query OK, 0 rows affected (0.01 sec)

mysql> SELECT * FROM performance_schema.host_cache;
Empty set (0.00 sec)

Although slightly more manual, this change aligns with MySQL’s long-term strategy of replacing legacy administrative commands with SQL-standard operations.

Conclusion

MySQL 8.4 may not bring headline-grabbing features, but it marks a significant step forward in terms of security, stability, and operational best practices. With the deprecation of legacy authentication methods, improved InnoDB defaults, and smarter utilities like version-aware dumps, this release focuses on refinement and long-term maintainability.

As highlighted in this blog, upgrading to MySQL 8.4 is not a routine task, especially if you're coming from older versions. It's essential to review your replication settings, adjust user privileges, and rework deprecated configurations to ensure compatibility and security.

If you need assistance evaluating or implementing MySQL 8.4 in your environment, our team is here to help.

Contact us at: sales@mafiree.com
Let us support your upgrade journey and ensure a smooth, optimized transition to MySQL 8.4 .