MySQL has come a long way since the introduction of the 8.0 series.
With the release of MySQL 8.4 in April 2024, Oracle has delivered a Long-Term Support (LTS) release that’s poised to become the backbone for enterprise-grade deployments over the next decade.
While version 8.4 may seem like a minor bump, it marks a clear boundary line between the evolving 8.x ecosystem and the future that will be ushered in by MySQL 9.0.
This article offers a side-by-side breakdown of key differences, changes in behavior, and configuration shifts that can affect performance, compatibility, and operations.
Table of Contents
Recommended MySQL LTS Versions (as of 2025)
- MySQL 5.7 was released in 2015 and reached end of support in October 2023. It’s no longer maintained and should be avoided for new deployments.
- MySQL 8.0, launched in 2018, is still under long-term support until April 2026. It remains a stable choice for many production systems.
- MySQL 8.4, released in April 2024, is the latest Long-Term Support (LTS) version. It will be supported until April 2032, making it the best option for projects that need long-term stability and up-to-date features.
🔄 New Release Strategy
- 8.4 is the first official LTS version.
- Oracle now follows a predictable pattern:
- LTS every 2 years
- Innovation releases (short-term) every 3 months
- This gives users a clear upgrade path and peace of mind for long-term deployments.
📌 MySQL 8.4 at a Glance
- Release Date: April 2024
- LTS Support Duration:
- Premier Support: 5 years
- Extended Support: 3 additional years (until ~April 2032)
- What This Means:8.4 is the final release in the 8.x series — there will be no 8.5.
🔐 Default Authentication Plugin
❓ What was the problem?
Earlier MySQL versions supported both caching_sha2_password and the older, less secure mysql_native_password. Many systems still used the outdated plugin, posing security risks.
🟢 What’s the solution?
In MySQL 8.4, mysql_native_password is disabled by default to encourage more secure practices.
✅ Why is this good?
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
- Promotes stronger, modern encryption methods
- Reduces risk of insecure configurations during upgrades
- Helps you prepare for MySQL 9.0, where
mysql_native_passwordwill be completely removed
👉 Example:
If your app still uses mysql_native_password, it’s like locking your front door with a rusty key. You can still do it, but it’s risky — and in the future, that key won’t fit at all.
📚 Replication Terminology Modernization
❓ What was the problem?
Older MySQL used MASTER and SLAVE to describe replication roles — terms now seen as outdated and unclear.
🟢 What’s the solution?
MySQL 8.4 replaces these with SOURCE and REPLICA.
✅ Why is this good?
- Aligns with industry-wide inclusivity practices
- Makes replication roles easier to understand and document
👉 Example:
New engineers onboarding no longer have to guess what “slave” does. SOURCE → REPLICA tells the story clearly.
🔗 Foreign Key Constraints Enforcement
❓ What was the problem?
MySQL 8.0 allowed foreign keys to reference non-unique columns, which could silently cause integrity issues.
🟢 What’s the solution?
MySQL 8.4 enforces that foreign keys must reference unique keys in the parent table.
✅ Why is this good?
- Prevents hidden data integrity bugs
- Makes schema design more predictable and standards-compliant
👉 Example:
Imagine you’re linking invoices to customers. If multiple customers had the same ID, how would the database know which one is the real parent? Now, it insists IDs be unique — as they should be.
🔢 AUTO_INCREMENT on FLOAT/DOUBLE
❓ What was the problem?
In older versions, using AUTO_INCREMENT on FLOAT or DOUBLE was technically allowed — but unsafe due to precision issues.
🟢 What’s the solution?
MySQL 8.4 removes this capability entirely. It now returns an error if you try.
✅ Why is this good?
- Prevents bugs caused by unpredictable auto-increment values
- Encourages better data modeling with
INTEGERbased IDs
👉 Example:
Tracking invoice numbers with a FLOAT is like counting dollar bills using a scale — it might work… until it doesn’t.
🚫 FLUSH HOSTS Removal
❓ What was the problem?
FLUSH HOSTS was used to clear blocked hosts, but lacked observability and fine-grained control.
🟢 What’s the solution?
MySQL 8.4 replaces it with:
TRUNCATE TABLE performance_schema.host_cache;
✅ Why is this good?
- Lets you monitor the host cache
- More transparent and maintainable
👉 Example:
Instead of just resetting a misbehaving server, now you can see what’s going wrong — and fix it more precisely.
Would you like me to continue the rest of the list (e.g., privileges, InnoDB changes, etc.) in this same style?
🛡️ SET_USER_ID Privilege Overhaul
❓ What was the problem?
In MySQL 8.0, the SET_USER_ID privilege was broad — it allowed routines and views to execute with another user’s rights, but with limited control.
🟢 What’s the solution?
MySQL 8.4 introduces finer-grained privileges:
SET_ANY_DEFINER: Lets a user define objects with any definer.ALLOW_NONEXISTENT_DEFINER: Permits definers that don’t exist.
✅ Why is this good?
- Improves security by avoiding privilege escalation
- Enables safer deployment pipelines and backup/restore workflows
👉 Example:
You can now safely import a routine from staging that was defined by a non-existent dev_user, without having to recreate that user on production.
🧠 innodb_buffer_pool_in_core_file Change
❓ What was the problem?
In MySQL 8.0, core dumps included the massive InnoDB buffer pool — often several GBs — making debugging painful and files enormous.
🟢 What’s the solution?
In 8.4, the default is now OFF, so the buffer pool is excluded from core dumps.
✅ Why is this good?
- Smaller core dumps
- Easier and faster to debug issues
👉 Example:
If your server crashes, you no longer need to sift through a 10 GB file to find a 2 KB bug.
⚙️ innodb_change_buffering Default Update
❓ What was the problem?
MySQL 8.0 defaulted to innodb_change_buffering=all, which could delay index updates — not ideal on fast storage like SSDs.
🟢 What’s the solution?
In 8.4, the default is none.
✅ Why is this good?
- Speeds up write-heavy workloads
- Reduces unnecessary background buffering on modern hardware
👉 Example:
Think of this like writing changes directly to disk instead of keeping a sticky note. On fast drives, direct is faster.
🚫 innodb_adaptive_hash_index Now Disabled
❓ What was the problem?
Adaptive Hash Indexing (AHI) in 8.0 was always on by default — but only benefitted certain workloads, and could even hurt performance in others.
🟢 What’s the solution?
8.4 disables it by default. You can still enable it manually and dynamically.
✅ Why is this good?
- Gives you control
- Prevents accidental performance degradation
👉 Example:
If you run a high-concurrency OLTP workload, turning AHI off might actually improve performance. Benchmark both!
🧱 innodb_doublewrite_pages Behavior Simplified
❓ What was the problem?
In 8.0, the number of pages written to the doublewrite buffer varied depending on other settings, like innodb_write_io_threads.
🟢 What’s the solution?
MySQL 8.4 uses a fixed default: 128 pages.
✅ Why is this good?
- Predictable, consistent write behavior
- Easier to tune and benchmark
👉 Example:
You no longer have to guess how many pages MySQL is double-writing — it’s now always 128 unless configured otherwise.
🚀 innodb_flush_method Now Uses O_DIRECT
❓ What was the problem?
fsync (the default in 8.0) caused double buffering — MySQL wrote data, then the OS wrote it again, wasting I/O.
🟢 What’s the solution?
In 8.4, the default is O_DIRECT (if supported), which bypasses OS cache.
✅ Why is this good?
- Reduces memory usage
- Improves I/O efficiency on modern SSD-based systems
👉 Example:
This is like writing a file straight to disk instead of first putting it in a clipboard. Less memory, more speed.
📈 innodb_io_capacity Modernized
❓ What was the problem?
The default value in 8.0 was 200 — a relic from when spinning disks were common.
🟢 What’s the solution?
8.4 bumps the default to 10,000 to reflect SSD and NVMe speeds.
✅ Why is this good?
- MySQL can flush more I/O in parallel
- Reduces latency under load
👉 Example:
If you’re using a high-performance RAID or NVMe disk, MySQL now uses its full potential instead of artificially slowing down.
📝 innodb_log_buffer_size Increased
❓ What was the problem?
With only 16 MB in 8.0, the log buffer could fill quickly under high write workloads, causing frequent flushes.
🟢 What’s the solution?
8.4 increases the default to 64 MB.
✅ Why is this good?
- Reduces disk I/O pressure
- Improves write throughput and stability
👉 Example:
Like having a bigger outbox — you can send more data at once instead of walking to the mailbox every 2 minutes.
