MySQL 8.0

MySQL 8.0 was a substantial change from the preceding 5.7 line. It introduced a transactional data dictionary stored in InnoDB, replacing many file-based metadata structures, and added atomic DDL for many schema operations. SQL capabilities expanded with common table expressions, window functions, descending indexes, invisible indexes, histograms, and improved GIS support. It added roles for privilege management, resource groups, the Clone plugin, and the X DevAPI and Document Store interfaces. The default character set changed to utf8mb4, with a newer default Unicode collation, and caching_sha2_password became the default authentication plugin. These changes improved correctness, administration, and SQL expressiveness, but they also created compatibility considerations for older clients, authentication setups, character-set assumptions, and operational tooling.

This cycle has reached end of life, so remaining on it leaves newly discovered defects and security issues without vendor fixes for the line. The risk is not limited to the server: supported driver, operating-system, backup, monitoring, and managed-service combinations may increasingly target newer MySQL releases instead. Continuing to run 8.0 can preserve short-term application stability, but it raises the cost of later migration as schemas, client libraries, and deployment automation drift further from a supported target. Teams using older authentication clients, mysql_native_password accounts, legacy SQL behavior, or replication topologies should expect compatibility work during a move, rather than assuming an upgrade will be transparent. End-of-life status also makes incident response harder because vendor support and documented remediation for 8.0-specific problems are no longer available.

Choose a supported target release and confirm that it is supported by the hosting model, operating system, client drivers, connectors, backup tooling, and replication design in use. First update the existing server to the latest available 8.0 maintenance release permitted by the upgrade path, then run MySQL Shell's upgrade checker against the intended target version. Resolve every reported incompatibility, including deprecated or removed server variables, invalid object definitions, reserved-word conflicts, authentication-plugin use, character-set and collation assumptions, and SQL-mode dependencies. Rehearse the upgrade from a production-like backup or clone, measure downtime and rollback time, and validate application queries, stored programs, events, replication, backups, restores, and failover procedures on the target. For replicated deployments, plan the upgrade order and promotion rules before changing production; commonly, replicas are upgraded and validated before the source. Keep a tested backup and restore path, define acceptance checks for data and application behavior, and schedule the production migration only after the rehearsal demonstrates that those checks pass.