Finding the MySQL version
MySQL latest version is 8.4 LTS, the long-term-support release that Oracle shipped on 18 July 2024, and it is the build you install on a production Linux server when you need a supported, patching cadence measured in years rather than months.
MySQL 8.4 is the current general-availability line, it follows the 8.0 series that has carried most Linux hosts since 2018, and it is the version whose release notes, security advisories, and community tooling you will read for the next 5 years of support. Finding the exact build on your machine, understanding which release line is current, and knowing how the LTS and innovation tracks differ are the 3 skills this page covers.
If you are already running a LAMP stack and need to verify which MySQL build is serving your database before you touch the configuration, the commands below will give you the answer in under 10 seconds. For the broader context of how MySQL fits into a production Linux environment, see MySQL in practice. If you prefer a graphical interface over the command line, a MySQL Workbench walkthrough will walk you through the same version-check steps in a visual tool. When your stack evaluation includes a second relational engine, the trade-offs are laid out in Choosing between MySQL and PostgreSQL, and if a runaway query is holding a lock while you are checking versions, you will need to know how to Kill a Process on Linux before the connection pool dries up.
Current MySQL release as of September 2026
The current MySQL release as of September 2026 is 8.4 LTS, and the innovation track is on 9.x. Oracle ships MySQL on 2 tracks: the long-term-support line, which receives security patches and bug fixes for 5 years from general availability, and the innovation line, which introduces new features and is supported for only 12 months. MySQL 8.4 LTS is the build you should deploy on a production server, because the 5-year window means you are covered through at least mid-2029 without a forced migration. The previous LTS, MySQL 8.0, entered its extended-support phase in April 2026, so new installations should target 8.4. Oracle publishes the full version matrix, with build numbers and end-of-life dates, on the MySQL Support page, and the date you see there is the one to quote when a client asks which release they are running.
How to check the MySQL version on Linux
To check the MySQL version on a Linux host, you run one of the commands below and read the string it returns. Each method works against a running daemon, so the server must be up, and each returns the same 3-part version string: major, minor, and revision. The CLI method is the fastest; the SQL method is the one to use when you are already inside a client session or writing a diagnostic script.
| Method | Command | What it returns |
|---|---|---|
| CLI, server side | mysql --version | Client build string, e.g. mysql Ver 8.4.2 for Linux |
| CLI, server binary | mysqld --version | Server build string, e.g. mysqld Ver 8.4.2 for Linux |
| SQL, version variable | SELECT VERSION(); | 8.4.2 (or the exact running build) |
| SQL, status variable | SHOW VARIABLES LIKE 'version'; | version 8.4.2 |
| Packaging manager | rpm -q mysql-server | Packaged build, e.g. mysql-server-8.4.2-1.el9.x86_64 |
The difference between the client and server strings matters when you have a multi-host setup: a client on one box may report 8.4.2 while the server on another reports 8.4.1, and the replication channel will still work because the wire protocol is backward compatible within the same major version. If the two versions drift by a minor release, check the binary log format and the group-replication plugin before you attempt an upgrade, because a plugin compiled against 8.4.1 will not load under 8.4.2 without a recompile.
Release cadence: innovation track versus LTS track
The release cadence of MySQL is a 2-track schedule: the innovation line ships roughly every 12 months and the LTS line ships every 3 years, which is why the 8.0 series ran from 2018 through 2026. The innovation track is where Oracle lands experimental features such as the invisible indexes introduced in 8.0.13, the atomic DDL improvements in 8.0.16, and the cloning plugin that landed in 8.0.23. Once a feature stabilises across 2 innovation releases, Oracle back-ports it to the LTS line, so you do not have to wait for the next 3-year cycle to use it. The practical rule is: deploy the latest patch of the current LTS, and evaluate the latest innovation release in a staging environment to decide whether the new feature is worth a 5-year commitment.
- MySQL 8.0 LTS: general availability 13 April 2018, extended support ended April 2026, 8-year total support window
- MySQL 8.4 LTS: general availability 18 July 2024, support runs to at least July 2029, 5-year window
- MySQL 9.x innovation: feature releases roughly every 12 months, 12-month support per build
Upgrading from MySQL 5.7 to 8.4 on a live Linux host
Upgrading from MySQL 5.7 to 8.4 on a live Linux host is a 2-step process because there is no direct in-place path: 5.7 is end-of-life, so you must move through 8.0 first, run mysql_upgrade, and then step up to 8.4. The total downtime for a 50 GB database on a 4-core VM is typically 20 to 35 minutes, most of which is the table-check phase. Before you start, snapshot the data directory with LVM or a file-level copy, because the upgrade script rewrites the data dictionary and a corrupted dictionary is not recoverable from a 5.7 backup. After the upgrade, verify that every stored procedure, trigger, and event still compiles, because 8.4 tightened the SQL mode defaults and a strict-mode violation will surface at first call, not at startup.
Common version-related errors and where to look
Common version-related errors on a MySQL Linux host are the ones that appear in the error log as a mismatch between the client protocol and the server protocol, and the fastest way to diagnose them is to compare the 3-part version strings from both sides. The 3 errors you will see most often are the authentication plugin mismatch when a 5.7-era application connects to an 8.4 server (the default plugin changed from mysql_native_password to caching_sha2_password in 8.0), the binary-log format error when a replication channel spans two different minor versions, and the InnoDB data-directory version mismatch when you copy a 5.7 data directory into an 8.4 install without running mysql_upgrade. Each of these is logged with a numeric error code in /var/log/mysqld.log on RHEL-based systems or /var/log/mysql/error.log on Debian-based systems, and the code maps directly to the MySQL error reference. If the error log shows a lock wait and the version strings match, the problem is not a version mismatch; it is a long-running transaction, and you need to identify the holding session before you escalate to killing the process on the host.