What’s New in MySQL 8.4 LTS: Key Enhancements Explained

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.

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?

• Promotes stronger, modern encryption methods
• Reduces risk of insecure configurations during upgrades
• Helps you prepare for MySQL 9.0, where mysql_native_password will 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.